Hi @bulky-afternoon-92433, I’m planning to focus on the “Metadata service request improvements” project for GSoC 2026, and I’ve started reading through the Metaflow client/runtime paths to understand the current metadata access patterns and compatibility constraints. In parallel, I’ve been working on #2734 to get familiar with the the runtime/client boundary through a smaller bug first. My understanding of #2734 is: -

namespace(None)

at module scope is meant to represent the global namespace - in the current runtime path, that value crosses into the worker as

None

- that seems to explain the reported

Object not in namespace ''

regression The correction I’m proposing is to normalize that empty worker-side namespace value back to

None

. Concretely: - change

namespace(opt_namespace)

to

namespace(opt_namespace or
  None)

- apply that in both

step

and

spin_step

For the metadata-service project, my current view is that the main challenge is introducing pagination and request-level filtering without changing client traversal semantics or causing older clients to observe incomplete results. My instinct is to start with the highest-volume list/read paths first, make pagination compatible and transparent in the client, and then move filtering down to the request layer. If this feels like the right direction, I’d really love to hear what you think would be the best place to start and which endpoints or traversal paths are most worth focusing on first.

for the

#2734

issue, feel free to open a PR with a suggested fix. If submissions were still blocked for the time being on the main repo, you can do this on your fork instead. Also do you happen to have a summary on what change introduced the regression? For any GSoC related discussions we have #C0AGE0SJPU1 and project specific channels. There are some repositories linked on the gsoc channel's pinned messages with starter issues for the projects. Your proposed plan seems like a sensible direction to focus on.