Message Start Events in Ed

[danfunk]

Sets up a Custom Start Event that will allow us to handle start event messages in the same we handle receive messages when executing in Ed. It will present a form based on the message schema, and allow tests to run against the process.

[coderabbitai]

Important

Review skipped

Review was skipped as selected files did not have any reviewable changes.

💤 Files selected but had no reviewable changes (3)

• docs/_themes/spiffworks/layout.html
• docs/_themes/spiffworks/static/spiffworks.css
• docs/_themes/spiffworks/theme.conf

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: b53b1ffd-de73-491a-8309-45d10674764a

📥 Commits

Reviewing files that changed from the base of the PR and between 5952e75 and 060ab44.

📒 Files selected for processing (3)

• docs/_themes/spiffworks/layout.html
• docs/_themes/spiffworks/static/spiffworks.css
• docs/_themes/spiffworks/theme.conf

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

📝 Walkthrough

Walkthrough

Adds a CustomStartEvent and converter to distinguish message vs non-message BPMN start events, wires them into the parser and SPIFF_CONFIG, adjusts greedy advancement to continue past non-message start events, and bumps package version to 0.1.37.

Changes

StartEvent Customization

Layer / File(s)	Summary
Version increment spiff-arena-common/pyproject.toml	Package version updated from 0.1.36 to 0.1.37.
StartEvent customization implementation spiff-arena-common/src/spiff_arena_common/runner.py	Adds imports for StartEvent parsing/serialization; defines CustomStartEvent and CustomStartEventConverter; routes startEvent parsing through SpiffStartEventParser + CustomStartEvent; registers custom converter in SPIFF_CONFIG and removes default StartEvent mapping; updates _advance_workflow greedy logic so non-message CustomStartEvent no longer breaks the loop while message start events still do.

Sequence Diagram

sequenceDiagram
  participant Workflow
  participant CustomStartEvent
  participant MessageCheck
  participant UpdateHook
  participant RunMethod
  Workflow->>CustomStartEvent: parse and instantiate
  CustomStartEvent->>MessageCheck: is_message_event?
  alt Message Start Event
    MessageCheck->>UpdateHook: bypass message waiting
    UpdateHook->>RunMethod: pause execution
    RunMethod-->>Workflow: return None (await user payload)
  else Non-Message Start Event
    MessageCheck->>Workflow: retain default behavior
    Workflow->>Workflow: greedy loop continues
  end

Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

• sartography/spiff-arena#2459: Modifies the runner module and parser/serializer integration for StartEvent handling; code-level related.

Suggested reviewers

• jbirddog

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% 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 'Message Start Events in Ed' directly relates to the main change, which implements custom start event handling for message-based start events in the Ed reactor environment.
Description check	✅ Passed	The description accurately describes the changeset—it explains that custom start event handling is being set up to manage start event messages in Ed, matching how receive messages are handled during execution.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ 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/messages_in_ed_reactor

---

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: 1

🤖 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 `@spiff-arena-common/pyproject.toml`:
- Line 3: pyproject.toml was bumped to 0.1.37 but uv.lock still pins
spiff-arena-common to 0.1.36; regenerate the lockfile so the spiff-arena-common
entry in uv.lock matches version 0.1.37 (e.g., run your project's lock/update
command to refresh uv.lock), verify the spiff-arena-common stanza shows 0.1.37,
and commit the updated uv.lock alongside the pyproject.toml change.

🪄 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: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 2e4fe0a8-60f9-4ad4-aeaf-e0b21114a612

📥 Commits

Reviewing files that changed from the base of the PR and between 8f25508 and 2c4c728.

📒 Files selected for processing (2)

• spiff-arena-common/pyproject.toml
• spiff-arena-common/src/spiff_arena_common/runner.py

[coderabbitai]

⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Regenerate uv.lock to match the package version bump.

pyproject.toml is now 0.1.37, but the provided uv.lock snippet still pins spiff-arena-common at 0.1.36. Please refresh the lockfile so dependency metadata stays consistent.

🤖 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 `@spiff-arena-common/pyproject.toml` at line 3, pyproject.toml was bumped to
0.1.37 but uv.lock still pins spiff-arena-common to 0.1.36; regenerate the
lockfile so the spiff-arena-common entry in uv.lock matches version 0.1.37
(e.g., run your project's lock/update command to refresh uv.lock), verify the
spiff-arena-common stanza shows 0.1.37, and commit the updated uv.lock alongside
the pyproject.toml change.

[jbirddog]

Would regen uv.lock like coderabbit suggests else the next pr will have to do it