How to properly handle custom status after phase 3, 4 interception

ModSecurity version (and connector): ModSecurity v3.0.13 with nginx-connector v1.0.3
WebServer: nginx-1.27.2
OS (and distro): alpine:3.20.3

Description

I am trying to implement custom HTTP status codes for deny actions across all phases.

When setting the default action for phase 1 and 2 using the following configuration:

SecDefaultAction "phase:1,nolog,auditlog,deny,status:419"
SecDefaultAction "phase:2,nolog,auditlog,deny,status:419"

ModSecurity correctly intercepts the request and responds with HTTP 419 as expected.

However, when I do not define default actions for phase 3 and 4, triggering rules in these phases only results in audit logs being generated, and the request is not blocked — the response is HTTP 200.

When I then add default actions for phase 3 and 4:

SecDefaultAction "phase:3,nolog,auditlog,deny,status:419"
SecDefaultAction "phase:4,nolog,auditlog,deny,status:419"

I see the audit log reporting http_code: 419, but the actual response received by the client is HTTP 502.

My Goal

I want to enforce a custom status code (e.g., 419) for phase 3 and 4 deny actions, just like in phase 1 and 2.

Questions

I want to enforce custom status codes (such as 419) in the reject operations of stages 3 and 4, just like in stages 1 and 2. How specifically do I need to modify the configuration?

Test Rule

SecRule RESPONSE_BODY "@pmFromFile php-errors.data" \
    "id:953100,\
    phase:4,\
    block,\
    capture,\
    t:none,\
    msg:'PHP Information Leakage',\
    logdata:'Matched Data: %{TX.0} found within %{MATCHED_VAR_NAME}',\
    tag:'application-multi',\
    tag:'language-php',\
    tag:'platform-multi',\
    tag:'attack-disclosure',\
    tag:'paranoia-level/1',\
    tag:'OWASP_CRS',\
    tag:'capec/1000/118/116',\
    tag:'PCI/6.5.6',\
    ver:'OWASP_CRS/4.10.0',\
    severity:'ERROR',\
    setvar:'tx.outbound_anomaly_score_pl1=+%{tx.error_anomaly_score}'"

Start by reproducing the phase 3 and 4 behavior with the shown SecDefaultAction settings and test rule 953100, comparing the audit log status with the client response. Trace how the nginx connector handles denied responses from these phases; done means identifying the required configuration or documenting a connector limitation for custom status codes.