FsOverrideEventListener Failure

Alert / Symptom

The listener logs log.error(…​) on any exception during async FS override dispatch, which is picked up by Google Cloud Error Reporting and fires the standard error-reporting notification channel. The error group will contain the log line:

Failed to apply FS override patch [tenantSchema=<schema>, fsUuid=<uuid>]

A secondary signal is a user ticket: "I hit Apply in the org-sync modal and selected several years, but only the årsoppgjør I was viewing got the override — the others still show the new name."

The listener catches all exceptions and logs the error; the event is not retried automatically. The error-reporting alert is the only automatic signal.

Impact

  • The affected FS never received its per-FS override, so it will render the new org name / establishedAt (same as the live org).

  • The org row and the currently-viewed FS (immediate-leg dispatch) are unaffected.

  • Any other FSes in the same fan-out whose events landed successfully are also unaffected.

Diagnose

Confirm the successful dispatches in the log (success path also emits a log line since the #2 follow-up):

resource.type="k8s_container"
jsonPayload.loggerName="tritt.finsta.service.org.FsOverrideEventListener"

Compare Applied async FS override […​] entries against the Failed to apply FS override patch […​] entries to identify which fsUuid values are missing an override.

Read the exception on the failed entry to determine root cause (typical: OptimisticLockException on concurrent save, database transient error, missing tenant schema).

Mitigate

The user can re-trigger the sync for the affected FS:

  1. Open Innstillinger on the affected årsoppgjør.

  2. Under Virksomhet, click the sync icon.

  3. Confirm the override in the modal.

This dispatches through the immediate leg (not async), and takes effect in the same request. See Organisasjons-synk for the full sync flow.

Resolve

Depending on root cause:

Transient DB / optimistic-lock error

The event is already consumed and lost. Ask the user to re-trigger the sync (see Mitigate above).

Tenant schema resolution failure

Check whether the event carried a valid tenantSchema. If the schema has been deleted or renamed between publish and dispatch, the override cannot be applied. Inspect organization.pendingBrregSync for the tenant — if still non-null the user can re-run sync; if null the tenant’s org row already has the new values.

Widespread failure (many tenants)

Likely infrastructure problem (DB, executor saturation). Check the dedicated fs-override-propagation executor’s queue depth and thread utilization.

Escalate

If the root cause is unclear or the error persists across multiple tenants, escalate to the backend team. The owning code is FsOverrideEventListener and FsOverridePropagator in finsta-service (package tritt.finsta.service.org).

See TenantUpdatedEventListener Failure for the upstream listener that seeds pendingBrregSync.