Skip to content

Fix websocket env_id: enrich the generic notify trigger - #112

Open
popen2 wants to merge 1 commit into
mainfrom
claude/platz-fix-ws-env-id
Open

popen2 wants to merge 1 commit into
mainfrom
claude/platz-fix-ws-env-id

Conversation

@popen2

@popen2 popen2 commented Jun 14, 2026

Copy link
Copy Markdown
Member

Critical fix — live websocket updates are broken on main

There are two parallel notification trigger systems:

  • The generic notify_trigger() is attached to every table and notifies the db_notifications channel. This is the channel the API's websocket feed listens on (main.rsNotificationListeningOpts::all()).
  • The per-table notify_specific_trigger_name() notifies db_<table>_notifications, consumed by the backend services (k8s-agent, status-updates, resource-sync, chart-discovery).

The earlier env_id enrichment landed on the per-table function, not the generic one the API reads. As a result, websocket events reaching the frontend carry no env_id, and with the per-env subscription + permission filtering, every environment-scoped event is dropped — live updates don't reach the UI.

What this does

  1. New migration enriches the generic notify_trigger() with the changed row's environment, resolved per table:

    • deployments / deployment_tasksk8s_clusters.env_id (via cluster_id)
    • deployment_resourcesdeploymentsk8s_clusters.env_id
    • secrets / env_user_permissions / deployment_permissions → their env_id column
    • envs → its own id
    • everything else → null (not environment-scoped)

    Because the trigger uses OLD on DELETE, the env is resolved even for deletions.

  2. Wildcard subscription matching: a subscription with no env is now a wildcard ("every permitted event of this table"). Globally loaded collections (envs, env_user_permissions) — whose events now carry an env_id — keep reaching subscribers, still gated by the permission scope. Env-scoped subscriptions remain exact-match.

Testing

Verified against a live PostgreSQL that db_notifications payloads carry the correct env_id for every environment-scoped table (deployments, tasks, resources, secrets, permissions, envs) including on DELETE, and null for global tables. cargo build + cargo fmt clean.

This is a prerequisite for the live per-env deployment counts work, which builds on env-tagged events.

https://claude.ai/code/session_019WuF56UqDxdJkYmk4zXD88


Generated by Claude Code

The API's websocket feed listens on the generic `db_notifications` channel,
fed by `notify_trigger()`. The earlier env_id work enriched
`notify_specific_trigger_name()` instead, which only feeds the per-table
channels used by backend services -- so websocket events reaching the
frontend carried no env_id, and per-env subscription/permission filtering
dropped every environment-scoped event (live updates were broken).

- New migration enriches the generic `notify_trigger()` with the changed
  row's environment, resolved per table (deployments/tasks/resources via
  cluster; secrets/permissions via their env_id column; envs via their own
  id). Other tables carry a null env_id.
- Websocket subscription matching now treats a no-env subscription as a
  wildcard ("every permitted event of this table"), so globally loaded
  collections such as envs and env_user_permissions -- whose events now
  carry an env_id -- still reach subscribers, gated by permissions.

Verified against PostgreSQL that db_notifications payloads carry the
correct env_id for every environment-scoped table, including DELETE.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Development

Successfully merging this pull request may close these issues.

2 participants