Skip to content

Add serde support to bevy_dev_tools inspection types - #25866

Merged
alice-i-cecile merged 1 commit into
bevyengine:mainfrom
jbuehler23:jackdaw/inspector-serde
Sep 24, 2026
Merged

alice-i-cecile merged 1 commit into
bevyengine:mainfrom
jbuehler23:jackdaw/inspector-serde

Conversation

@jbuehler23

@jbuehler23 jbuehler23 commented Sep 21, 2026 •

Copy link
Copy Markdown
Contributor

Objective

Part of #23013.

The inspection types can be built and displayed but not sent anywhere. Remote tooling needs them as JSON, and an editing client needs the actual field values, not just a display string.

Ported from feathers_inspector, phase 4.3 of the upstreaming strategy there. Builds on #25823 and #25845.

Solution

Serde support for the inspection types behind the serialize feature, plus structured values.

  • with helpers for component id, archetype id, debug name, storage type, the metadata map and spawn details
  • serde derives on the inspection and metadata types, with reflected values and type registrations skipped
  • a serialized_value on component and resource inspections, filled through the typed reflect serializer when the new include_serialized_value setting is on
  • the feature now pulls in serde_json and the ecs, platform and utils serialize features

The two error types with a static string variant are serialize only. Spawn details serialize as tick and location and deserialize to none.

AI disclosure

AI assistance was used to help port these changes and to plan this upstream series from our existing Jackdaw functionality. All changes were reviewed by a human before submission.

@jbuehler23
jbuehler23 force-pushed the jackdaw/inspector-serde branch from da5cbae to 950d43f Compare September 21, 2026 07:53
@jbuehler23 jbuehler23 added C-Feature A new feature, making something new possible A-Dev-Tools Tools used to debug Bevy applications. D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Sep 21, 2026

@Nilirad Nilirad left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The implementation seems correct, apart from some rough coners on the inspection type fields that are difficult to judge on without real usage feedback (e.g. whether we should serialize "ComponentId", or serialize spawn_details but deserialize it back to None). Those concerns are very difficult to validate in a vacuum, so I don't block on that.

One thing to note is that despite what mentioned in the PR message, serialization for inspection summary types has not been added yet. This can easily be done in a followup PR, so I don't block on that. You can just remove the mention from the PR message.

Overall, it looks ok, and it looks very similar to the work I did months ago on feathers_inspector. Approved!

@jbuehler23

Copy link
Copy Markdown
Contributor Author

The implementation seems correct, apart from some rough coners on the inspection type fields that are difficult to judge on without real usage feedback (e.g. whether we should serialize "ComponentId", or serialize spawn_details but deserialize it back to None). Those concerns are very difficult to validate in a vacuum, so I don't block on that.

One thing to note is that despite what mentioned in the PR message, serialization for inspection summary types has not been added yet. This can easily be done in a followup PR, so I don't block on that. You can just remove the mention from the PR message.

Overall, it looks ok, and it looks very similar to the work I did months ago on feathers_inspector. Approved!

Thanks! Fixed the description, the summary serde derives ended up in #25883 alongside the BRP methods

@alice-i-cecile alice-i-cecile added S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it and removed S-Needs-Review Needs reviewer attention (from anyone!) to move forward labels Sep 24, 2026
@alice-i-cecile
alice-i-cecile added this pull request to the merge queue Sep 24, 2026
Merged via the queue into bevyengine:main with commit dbb989e Sep 24, 2026
44 checks passed
pull Bot pushed a commit to octoape/bevy that referenced this pull request Sep 25, 2026
Stacked on bevyengine#25866. Review the last commit only pls!

# Objective

Part of bevyengine#23013.

Expose the inspection backend over the Bevy Remote Protocol so remote
tools get labels, metadata, display strings and structured values from
one call instead of assembling them from raw queries.

Ported from feathers_inspector, phase 5 of the upstreaming strategy
there. The BRP module was originally written by @Nilirad.

# Solution

Seven instant methods in a new inspection methods module, registered
with the other defaults.

- `world.inspect` for an entity, `world.inspect_component` and
`world.inspect_component_type`
- `world.inspect_resource` and `world.inspect_all_resources`
- `world.summarize` for entity, archetype and resource counts
- `registry.component_metadata` for the type map clients cache

Structured values are always on for remote replies. Unknown type names
return a new error code. Serde derives for the world summary types are
here too since they were waiting on the serde PR.

Not exposed: the cached variant of inspect, multi-entity inspection and
fuzzy name lookup, which wait on bevyengine#25010 and bevyengine#25028.

# AI disclosure

This is part of the inspector upstreaming series. When I started it, I
worked out the goals and scope with Alice and used AI to split the
working Jackdaw and feathers_inspector code into small reviewable
pieces. For this one, AI did the mechanical port of the BRP verbs into
`bevy_remote` and wrote the tests, and I reviewed the code and had it
double check for problems. That turned up two things. CI never enables
the `client` feature, so the new integration tests (and the client's own
round trip tests from bevyengine#25837) would have compiled empty, which is why
`bevy_remote` now lists itself as a dev-dependency with `client` on.
CodeQL also flagged test assertions that printed whole JSON replies as
cleartext logging, so those messages are gone.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-Dev-Tools Tools used to debug Bevy applications. C-Feature A new feature, making something new possible D-Modest A "normal" level of difficulty; suitable for simple features or challenging fixes S-Ready-For-Final-Review This PR has been approved by the community. It's ready for a maintainer to consider merging it

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants