Add status change topic

[kevinwallimann]

Overview

See

• https://html-preview.github.io/?url=https://github.com/AbsaOSS/EventGate/blob/feature/151-review-docs/docs/151/status_change_infographics.html
• https://github.com/AbsaOSS/EventGate/blob/feature/151-review-docs/docs/151/adr_eventbus_statuschange.md

Release Notes

• Add status change topic

Related

Closes #151

Summary by CodeRabbit

• New Features

  • Added a status-change event topic with a comprehensive validation schema for job lifecycle events.

• Chores

  • Updated access configuration to include the new topic.
  • Updated configuration handling and unit tests to discover and list the new topic.

[coderabbitai]

Walkthrough

This PR adds a new status_change topic to EventGate by introducing a topic constant, defining a JSON Schema with typed fields and conditional validation rules for status-change events, configuring access control, and integrating topic discovery and loading into the existing handler and config loader systems. Test coverage is updated to verify the integration.

Changes

Status Change Topic Support

Layer / File(s)	Summary
Topic constant and schema definition src/utils/constants.py, conf/topic_schemas/status_change.json, conf/access.json	Topic constant TOPIC_STATUS_CHANGE is defined with value public.cps.za.status-change. The JSON Schema defines typed properties (UUID/epoch-millisecond formats), constrains event_type to lifecycle values, and adds conditional validation via allOf blocks: created events require source/platform/input fields, and finished events require and restrict status_type to SUCCEEDED | FAILED | KILLED. Access control maps the topic to TestUser.
Handler and config loader integration src/handlers/handler_topic.py, src/utils/config_loader.py	HandlerTopic imports the new constant and loads status_change.json during schema initialization. config_loader.py imports the constant and adds status_change.json to the topic filename-to-topic mapping in load_topic_names(), enabling automatic discovery.
Test coverage tests/unit/handlers/test_handler_topic.py, tests/unit/utils/test_config_loader.py	Handler tests add status_change.json to mocked schemas and verify the parsed topic and endpoint response include public.cps.za.status-change. Config loader tests update fixtures and expectations to verify discovery and exclusion behavior with the additional schema.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A small schema hops into place,
Fields aligned with tidy grace,
A constant, access, tests in flight,
Topics now wake to status light,
EventGate hums through day and night.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 66.67% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title 'Add status change topic' is concise and directly reflects the main change—adding a new status_change topic to EventGate.
Description check	✅ Passed	The PR description includes an Overview section with documentation references and a Release Notes section, matching the repository template structure.
Linked Issues check	✅ Passed	The PR successfully implements all acceptance criteria from issue #151: defines the status_change topic with JSON schema, makes it available in EventGate, and supports producer/consumer operations via existing API mechanisms.
Out of Scope Changes check	✅ Passed	All changes are narrowly scoped to adding the status_change topic infrastructure; no extraneous modifications to unrelated features or systems are present.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feature/151-add-status-change-topic

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

tests/unit/handlers/test_handler_topic.py (1)

90-90: ⚡ Quick win

Add one POST-path test for public.cps.za.status-change schema validation.

Current additions validate discovery/listing only. A valid + invalid POST case for the new topic would protect the end-to-end contract (load + validate + reject bad payloads) from regressions.

Also applies to: 103-107, 117-117

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@tests/unit/handlers/test_handler_topic.py` at line 90, Add a new test
function (e.g., test_post_status_change_schema_validation) in the existing
test_handler_topic suite that exercises the POST path for the schema named
"public.cps.za.status-change": send one valid POST payload (matching the schema,
e.g., including execution_id as string) and assert the handler accepts it
(status accepted/success), then send an obviously invalid payload (e.g.,
execution_id missing or wrong type) and assert the handler rejects it with a
validation error (400 or rejection response and an error message referencing the
schema/field); place both assertions in the same test to ensure load+validate
behavior is covered end-to-end.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@conf/topic_schemas/status_change.json`:
- Around line 20-33: The schema currently treats tenant_id as optional and lacks
explicit previous_state/new_state fields; update status_change.json to make the
application identifier required (mark "tenant_id" as required in the root
"required" array or otherwise add a required "application_id" equivalent), add
"previous_state" and "new_state" properties (type "string", non-nullable) to the
schema, and include those two fields in the schema's "required" array so every
status_change event must carry tenant_id plus previous_state and new_state;
apply the same changes to the other schema blocks noted (lines referenced in the
review).
- Around line 52-55: The schema defines "timestamp_event" as epoch milliseconds
but uses "type": "number" which allows fractions; change the "timestamp_event"
field in the JSON schema to use "type": "integer" (and add "minimum": 0 if you
want to enforce non-negative timestamps) so the schema enforces
whole-millisecond epoch values.

---

Nitpick comments:
In `@tests/unit/handlers/test_handler_topic.py`:
- Line 90: Add a new test function (e.g.,
test_post_status_change_schema_validation) in the existing test_handler_topic
suite that exercises the POST path for the schema named
"public.cps.za.status-change": send one valid POST payload (matching the schema,
e.g., including execution_id as string) and assert the handler accepts it
(status accepted/success), then send an obviously invalid payload (e.g.,
execution_id missing or wrong type) and assert the handler rejects it with a
validation error (400 or rejection response and an error message referencing the
schema/field); place both assertions in the same test to ensure load+validate
behavior is covered end-to-end.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 469ed8af-1aad-4a69-aa28-c2f10a0eb96a

📥 Commits

Reviewing files that changed from the base of the PR and between a0b6f6f and a6dc8b4.

📒 Files selected for processing (7)

• conf/access.json
• conf/topic_schemas/status_change.json
• src/handlers/handler_topic.py
• src/utils/config_loader.py
• src/utils/constants.py
• tests/unit/handlers/test_handler_topic.py
• tests/unit/utils/test_config_loader.py

[coderabbitai]

🧹 Nitpick comments (1)

conf/topic_schemas/status_change.json (1)

34-41: 💤 Low value

Minor: stray leading space in source_app description.

Line 36's description starts with a leading space (" Standardized source application name..."). Trivial cleanup while you're touching the field.

✏️ Proposed tweak

-            "description": " Standardized source application name (aqueduct, unify, lum, etc)"
+            "description": "Standardized source application name (aqueduct, unify, lum, etc)"

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@conf/topic_schemas/status_change.json` around lines 34 - 41, The description
value for the JSON schema field "source_app" contains a stray leading space;
update the "source_app" property's "description" (in status_change.json) to
remove the leading whitespace so it reads "Standardized source application name
(aqueduct, unify, lum, etc)" exactly, ensuring the JSON string has no extra
leading character.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@conf/topic_schemas/status_change.json`:
- Around line 34-41: The description value for the JSON schema field
"source_app" contains a stray leading space; update the "source_app" property's
"description" (in status_change.json) to remove the leading whitespace so it
reads "Standardized source application name (aqueduct, unify, lum, etc)"
exactly, ensuring the JSON string has no extra leading character.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 61200d85-a19c-420a-9e0c-38cd27ac8d69

📥 Commits

Reviewing files that changed from the base of the PR and between a6dc8b4 and c6e6750.

📒 Files selected for processing (1)

• conf/topic_schemas/status_change.json