[master] 5735a543c Insist that VCL_RET_FAIL goes through VRT_fail() and not VRT_handling()
Dridi Boukelmoune
dridi at varni.sh
Mon Feb 18 21:13:39 UTC 2019
> Which I don't think it should, because I dont see us backporting #2902
> where this comes from.
I take them in order, so I haven't revisited #2902 yet for the 6.0 branch.
This triggered during my weekly CI against master, on code that
actually predates the introduction of VRT_fail():
https://travis-ci.org/Dridi/libvmod-querystring/jobs/495041218#L2196
I believe we discussed it today during the bugwash, so it's
unfortunate that my cron job triggers on Monday afternoon because
simply VRT_fail()ing during vcl_init today will not feed the CLI error
message on older branches :)
To anyone interested in a workaround in case VRT_fail() doesn't feed
the error message starting with 6.2, or the people of the trunk
persuasion, I was able to handle both cases without trying too hard:
https://github.com/Dridi/libvmod-querystring/commit/6b63758
If I had more than one occurrence it wouldn't be too hard to wrap in a
function, and I believe the consensus during bugwash was to restore
the old behavior so I should be able to get rid of this after the March
release.
Dridi
More information about the varnish-commit
mailing list