nfx/slrp

Panic and crash when using filtering in Web UI

aslian opened this issue · 1 comments

Version https://github.com/nfx/slrp/releases/download/v0.0.7/slrp_0.0.7_linux_amd64.tar.gz.

Entering Session>2 or even S>2 in Search field or navigating to http://localhost:8089/history?filter=Session%3E2 crashes entire application

panic: interface conversion: interface {} is float64, not string

goroutine 27 [running]:
github.com/nfx/slrp/ql.(*ConditionOperand).eval(0xc002cdd8f0, {{0xbd8be0?, 0xc0006d0780?, 0x0?}, 0xc0041ed380?})
	/home/runner/work/slrp/slrp/ql/ast.go:234 +0x7e8
github.com/nfx/slrp/ql.(*Condition).eval(0x203000?, {{0xbd8be0?, 0xc0006d0780?, 0x0?}, 0xc0041ed380?})
	/home/runner/work/slrp/slrp/ql/ast.go:194 +0x4a
github.com/nfx/slrp/ql.(*AndCondition).eval(0x7ff378952850?, {{0xbd8be0?, 0xc0006d0780?, 0xc0?}, 0xc0041ed380?})
	/home/runner/work/slrp/slrp/ql/ast.go:173 +0xb1
github.com/nfx/slrp/ql.(*Expression).eval(0xbd6de0?, {{0xbd8be0?, 0xc0006d0780?, 0x4b3e6f?}, 0xc0041ed380?})
	/home/runner/work/slrp/slrp/ql/ast.go:45 +0xbd
github.com/nfx/slrp/ql.applyFilter[...](0xc000548118, 0xc0001cb8a8, 0xc0041ecfc0, 0x0)
	/home/runner/work/slrp/slrp/ql/ast.go:421 +0x237
github.com/nfx/slrp/ql.Execute[...](0xc000548118, 0xc0001cb8a8, {0xc0039c5930, 0x9}, 0xc004699a80, {0xc004699a90, 0x2, 0xc00})
	/home/runner/work/slrp/slrp/ql/ast.go:385 +0x273
github.com/nfx/slrp/history.(*History).handleFilter(0xc000548100, {{0xc0039c5930?, 0x6787668f00500000?}, 0xc0030c4660?})
	/home/runner/work/slrp/slrp/history/history.go:202 +0x189
github.com/nfx/slrp/history.(*History).main(0xc000548100, {0xef1c90, 0xc0002be510})
	/home/runner/work/slrp/slrp/history/history.go:192 +0x350
created by github.com/nfx/slrp/history.(*History).Start
	/home/runner/work/slrp/slrp/history/history.go:111 +0x95

I don't think that invalid search query should crash the entire app, honestly...

nfx commented

@aslian fully agree with that, it shouldn't. Fix aiming at v0.1.x Fixed in 65d175c and will be released in v0.0.8.

There's also upcoming rewrite to a new query engine and it'll get this problem fixed. There just needs to be a mapper from pmux.Proxy to float64 for this to become reality.