[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