You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
A malformed (Contextual Bandits) context sent to VW will only log to the log file, but the sender will receive a normal response and have no way to know they are providing a malformed context string to the daemon. To reproduce on the comman-dline:
$ echo "| a: 0:300" | netcat localhost 26542
Assume in the above case, the sender intends to obtain a distribution back from the daemon, but the context they provide is, as easily seen above, malformed.
An error will be logged, but a distribution will be returned as if it is a normal message. This will deeply hinder production integration workflows that expect "plain" software standards on the socket↔daemon channel, and can be a source of trouble for production code architectures interacting with the daemon. The solution should probably (or perhaps) be to introduce a special response replacing the normal one.
Confirmed on 8.5 and 8.6.1 as released (in both cases model used in the daemon trained on 8.5).
Please let me know if you can indeed reproduce...
The text was updated successfully, but these errors were encountered:
The core issue here is that there is no way for the daemon mode to report errors.
I'm not sure what to do about this. We aren't currently using the daemon mode, partly because more advanced communication protocols avoid this sort of failure.
A malformed (Contextual Bandits) context sent to VW will only log to the log file, but the sender will receive a normal response and have no way to know they are providing a malformed context string to the daemon. To reproduce on the comman-dline:
Assume in the above case, the sender intends to obtain a distribution back from the daemon, but the context they provide is, as easily seen above, malformed.
An error will be logged, but a distribution will be returned as if it is a normal message. This will deeply hinder production integration workflows that expect "plain" software standards on the socket↔daemon channel, and can be a source of trouble for production code architectures interacting with the daemon. The solution should probably (or perhaps) be to introduce a special response replacing the normal one.
Confirmed on
8.5
and8.6.1
as released (in both cases model used in the daemon trained on 8.5).Please let me know if you can indeed reproduce...
The text was updated successfully, but these errors were encountered: