As @Paul Watson predicted, there's now internal debate within HCL/IBM as to whether this constitutes a bug or a feature request. The alleged rationale is that the CM doesn't know that a server has DELAY_APPLY set and therefore can't decide not to fail over there. My counter was that if this isn't a bug in the CM, it's certainly a bug in the engine, _especially_ since the engine knows not to allow a DELAY_APPLY RSS to be promoted to an HDR secondary:
2022-10-09 11:18:11.249 SCHAPI: Issued Task() or Admin() command "task( 'ha set secondary', 'ids__chaos_hdr__b3' )".
2022-10-09 11:18:11.561 Secondary Delay or Stop Apply: A server type change from an RS Secondary to an
HDR Secondary is not allowed when the DELAY_APPLY or STOP_APPLY
configuration parameters are enabled and the delay or stop
subsystem is active.
Disable the DELAY_APPLY or STOP_APPLY configuration parameters and
retry the operation after any saved data is applied.
2022-10-09 11:18:12.561 SCHAPI: Issued command "task( 'ha set secondary', 'ids__chaos_hdr__b3' )". This is the only record of the command issu
ance.
I can't see any case to be made that it should refuse to convert DELAY_APPLY RSS->HDR but then happily convert DELAY_APPLY RSS->PRI, _especially_ without first rolling forward.
Tagging @Art Kagel and @Lester Knutsen for additional feedback.
------------------------------
TOM GIRSCH
------------------------------