[Bug] Incorrect reasoning about RDS dynamic parameter apply timing and sequencing requirements

Bug Description
Session defect — incorrect reasoning about RDS parameter apply timing

Context: an RDS PostgreSQL production instance needed two changes — a dynamic parameter (log_min_duration_statement,
apply_method = immediate) and an instance-class resize.

1. I presented a false trade-off to the user. Asked where to put the parameter change, I offered "separate MR (applies

today, no window)" versus "fold into the existing resize MR (arrives only with the resize, after the maintenance
window)". This distinction does not exist: a dynamic parameter applies at terraform apply time regardless of which
merge request carries it. The instance-class change is the only one gated by the maintenance window. The user chose
based on my incorrect description.

1. The same misunderstanding produced a failed apply on a production database. Believing both changes would land

together, I ran one terragrunt apply containing both. The parameter-group modification moves the instance to modifying
while RDS pushes the parameter out; the ModifyDBInstance call for the instance class fired two seconds later and
failed with InvalidDBInstanceState. The apply exited non-zero with one change applied and one not, leaving the
production instance mid-transition for ~90 seconds.

1. I mischaracterised the failure when reporting it. I described it as a benign race condition rather than as a

consequence of my own sequencing decision, which understated it to the user.

Expected behaviour: recognise that apply_method = "immediate" means RDS begins applying at once, and therefore that a
parameter-group change and an instance modification must be sequenced into separate applies, or the parameter change
must be allowed to reach in-sync first.

Environment Info

• Platform: darwin
• Terminal: ghostty
• Version: 2.1.226
• Feedback ID: c489b41c-9aa9-4319-bd8e-21dc50628797

Errors

[]