... assertion when preceded by the following error message:
ERROR: Inconsistent service method ... in dynamic adaptation chain
The assertion is triggered by the following chain of events. During
SslBump step1, a REQMOD adaptation service returns a dynamic
(X-Next-Services) plan containing a RESPMOD service P. Then, during
SslBump step2 (after obtaining TLS client SNI):
* Adaptation::AccessCheck::start() discovers P in the "future services"
storage (Adaptation::History::theFutureServices) and returns it.
* The adaptation routing code correctly concludes that P is not
applicable to the current vectoring point, logs the above ERROR, and
returns the untouched virgin message object to the adaptation
initiator. See thePlan.exhausted() in Adaptation::Iterator::step().
* ClientHttpRequest asserts because it expects a new message object.
Fixed Adaptation::AccessCheck code no longer assumes that it cannot be
activated twice for the same vectoring point. It leaves services
applicable to future vectoring points in theFutureServices instead of
always suggesting them for the current vectoring point.
TODO: We can and should optimize adaptation requesting code to stop
requiring a new message object when no adaptation is necessary, but that
change is difficult (we tried!) and independent from the bug fixed here.