Add status change topic#155
Conversation
kevinwallimann
requested review from
lsulak,
oto-macenauer-absa,
petr-pokorny-absa and
tmikula-dev
as code owners
|
Warning Rate limit exceeded
You’ve run out of usage credits. Purchase more in the billing tab. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
WalkthroughThis PR adds a new ChangesStatus Change Topic Support
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🧹 Nitpick comments (1)
tests/unit/handlers/test_handler_topic.py (1)
90-90: ⚡ Quick winAdd one POST-path test for
public.cps.za.status-changeschema 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
📒 Files selected for processing (7)
conf/access.jsonconf/topic_schemas/status_change.jsonsrc/handlers/handler_topic.pysrc/utils/config_loader.pysrc/utils/constants.pytests/unit/handlers/test_handler_topic.pytests/unit/utils/test_config_loader.py
| "job_ref": { | ||
| "type": [ | ||
| "string", | ||
| "null" | ||
| ], | ||
| "description": "Identifier of the job in it's respective system (e.g. Spark Application Id, Glue Job Id, EMR Step Id, etc)." | ||
| }, | ||
| "tenant_id": { | ||
| "type": [ | ||
| "string", | ||
| "null" | ||
| ], | ||
| "description": "Application ID or ServiceNow identifier" | ||
| }, |
There was a problem hiding this comment.
Schema contract does not enforce the required status-transition payload.
The objective says status_change must include an application identifier plus previous and new state. In this schema, tenant_id is optional, and there are no explicit previous_state / new_state fields, so producers can publish events that don’t carry a real transition.
Also applies to: 142-156, 179-185
🤖 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 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).
Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
1 participant
Overview
See
Release Notes
Related
Closes #151
Summary by CodeRabbit
New Features
Chores