Accept a null module configuration

[senamakel]

The v0.3.0 release built and published all sixteen platform bundles, and
TinyBus's own module host loaded the artifact — but the release workflow's final
step, verify_github_release, refused it with module initialization failed.

The cause

The loader's configuration slot is a serde_json::Value, and a host that
configures nothing leaves it at its default — which is null, not {}.
ModuleConfig carried #[serde(default)], which fills in absent fields but
does not accept a whole document of the wrong type, so decoding null failed
and setup returned before it could serve anything.

The unit test that was supposed to cover this decoded "{}". The empty object
is what the documentation called an absent configuration; null is what the
loader actually sends. So the module refused to load for exactly the host that
asked nothing of it, and said so in a message that names nothing useful.

The fix

ModuleConfig now has a hand-written Deserialize that decodes through
Option<Wire>, mapping null onto the default. The field handling is still
derived, on a private wire struct, rather than restated.

Behavior changes

A module loaded with null configuration now comes up instead of failing. No
other decoding changes: {} and a populated object behave exactly as before.

Tests

Three, covering the decode, the service built from it, and the whole
setup path a loader takes:

• a_null_configuration_decodes_to_a_working_default
• a_service_builds_from_a_null_configuration
• a_module_loaded_with_no_configuration_comes_up

The last one is the release verifier's scenario minus the download, so this
cannot regress into a release again without the suite saying so first.

Verified against the real artifact: verify_github_release reproduces the
failure against the published v0.3.0 bundle, which was built before this fix.

Validation

• cargo fmt --all -- --check — clean
• cargo clippy --all-targets --all-features -- -D warnings — clean
• cargo test --all-features — 657 passed, 0 failed
• cargo doc --no-deps --all-features with -D warnings — clean
• .github/scripts/check-file-coverage.sh 90 — passes

Summary by CodeRabbit

• Bug Fixes

  • Module configuration now handles null, empty objects, and omitted fields gracefully by applying default settings.
  • Modules can initialize successfully without explicit configuration.

• Tests

  • Added coverage for default configuration parsing, service creation, and initialization on an in-process bus.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: e0edc2cf-24b2-4132-b92a-6dc5b2c775a0

📥 Commits

Reviewing files that changed from the base of the PR and between f9621b8 and e82fd87.

📒 Files selected for processing (2)

• crates/tinymcp/src/tinybus_module/config.rs
• crates/tinymcp/src/tinybus_module/test.rs

Included review availability: Your plan provides up to 1 included review per hour; 0 remain after this review.

---

📝 Walkthrough

Walkthrough

ModuleConfig now uses custom deserialization. JSON null and empty objects produce defaults. Tests cover configuration decoding, service construction, and module startup on an in-process bus.

Changes

ModuleConfig handling

Layer / File(s)	Summary
Custom ModuleConfig deserializer crates/tinymcp/src/tinybus_module/config.rs	ModuleConfig uses a private Wire representation. null and missing fields resolve to default configuration values.
Configuration and startup tests crates/tinymcp/src/tinybus_module/test.rs	Tests verify null decoding, empty service construction, and successful module initialization on an in-process bus.

Estimated code review effort: 2 (Simple) | ~10 minutes

Merge Risk: ⚪ Minimal · up to e82fd

Null module configuration now starts the module with its existing empty defaults instead of failing initialization, while object configurations retain their prior behavior. No actionable merge-blocking risk remains after normal checks and review.

Poem

I’m a rabbit with config in my ear,
null now means defaults appear.
Empty services hop into place,
The bus starts clean in a steady pace.
Tests thump twice: “The module is here!”

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: accepting a null module configuration.
Docstring Coverage	✅ Passed	Docstring coverage is 80.00% which is sufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 5 functions across 2 files.
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.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

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.}

[tinysweeper]

tinysweeper found nothing blocking. Approving.

$0.0000 · 0 in / 0 out · 241 embedded · openrouter/openai/text-embedding-3-small

[tinysweeper]

How this change flows

2 changed behaviours across 4 relationships. 5 surrounding behaviours are shown (60 graph nodes walked). 48 further behaviours left out to keep the diagram readable.

flowchart LR
  n0["ModuleConfig<br/>changed"]:::changed
  n1["...at_cannot_open_its_store_fails_to_come_up<br/>changed"]:::changed
  n2["json"]:::impacted
  n3["service_at"]:::impacted
  n4["ok"]:::impacted
  n5["call"]:::impacted
  n6["catalog"]:::impacted
  n1 -->|uses| n0
  n3 -->|uses| n0
  n4 -->|calls| n5
  n6 -->|calls| n2
  classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
  classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
  classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
  classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff

Loading

_{Green: changed behaviour. Grey: surrounding behaviour. Arrows name the call, use, implementation, or test relationship. Orange: has findings. Red: has a finding that blocks the merge.}