Skip to content
Permalink
Browse files

Make r02433.vtc relevant again

With recent changes in the VCL state and temperature handling this test
case lost its relevance and started testing a no-op operation. And since
it wasn't apparently obvious what it was trying to check between two
possible interpretations it now tests both and better verifies it.

Reported by fgs.

When I initially wrote this test case it used to trigger a panic in the
then young VCL labeling.
  • Loading branch information...
Dridi committed May 15, 2019
1 parent b81fd3b commit e55d9eae55690ca8d60392090c247563a034ec52
Showing with 21 additions and 9 deletions.
  1. +21 −9 bin/varnishtest/tests/r02433.vtc
@@ -2,22 +2,34 @@ varnishtest "label a cold vcl"

server s1 { } -start

varnish v1 -cliok "param.set vcl_cooldown 0.1"
varnish v1 -vcl+backend {
import debug; # can fail a VCL warmup

sub vcl_recv {
return (synth(200));
}
} -start

# a dummy vcl to freely use vcl1
# a dummy vcl2 to freely use vcl1
varnish v1 -vcl+backend { }

# the magic parameter that fails a VCL warmup
# cool vcl1 down
delay 4
varnish v1 -cliok ping

shell -match "auto +cold" { varnishadm -n ${v1_name} vcl.list | grep vcl1 }

# first we try to label a cold VCL in auto state

# the magic parameter that fails a VCL warmup in vmod-debug
varnish v1 -cliok "param.set max_esi_depth 42"

varnish v1 -cliexpect "max_esi_depth is not the answer" "vcl.label label1 vcl1"

shell -err { varnishadm -n ${v1_name} vcl.list | grep label1 }

# second we try to label VCL in cold state
varnish v1 -cliok "vcl.state vcl1 cold"
varnish v1 -clierr 300 "vcl.label label1 vcl1"

# check that creating the label actually failed
varnish v1 -clierr 106 "vcl.discard label1"
shell -match "cold +cold" { varnishadm -n ${v1_name} vcl.list | grep vcl1 }

varnish v1 -cliexpect "set to auto or warm first" "vcl.label label1 vcl1"

shell -err { varnishadm -n ${v1_name} vcl.list | grep label1 }

0 comments on commit e55d9ea

Please sign in to comment.
You can’t perform that action at this time.