I think we don't want to use a plain array in place of a message definition object, because the local message corpus validation behavior should mirror the experiment message validation behavior as closely as possible, and the local message providers are top-level arrays, which apparently causes next-level arrays to be decoded as dictionaries (keyed by insertion index). So something like this ```json [ { "id": "MSG_1" }, { "id": "MSG_2" }, [{ "id": "MSG_3" }, { "id": "MSG_4" }, { "id": "MSG_5" }], { "id": "MSG_6" } ] ``` Is decoded like this ```json [ { "id": "MSG_1" }, { "id": "MSG_2" }, { "0": { "id": "MSG_3" }, "1": { "id": "MSG_4" }, "2": { "id": "MSG_5" } }, { "id": "MSG_6" } ] ``` And then the schemas would have to be changed to accept arbitrary keys, which seems unacceptable. Whereas if we do this: ```json [ { "id": "MSG_1" }, { "id": "MSG_2" }, { "messages": [{ "id": "MSG_3" }, { "id": "MSG_4" }, { "id": "MSG_5" }] }, { "id": "MSG_6" } ] ``` for some reason that avoids the problem. That said, this appears to be caused by serializing our local message providers. I don't think the nimbus path has this top-level array structure at any point. Messages would be validated as part of the recipe. So, as long as we didn't use these "message bundles" in local providers, it could still work. It just seems kinda bad to make the corpus testing behavior deviate from the experiment validation behavior. So for now, I'm gonna go with that - it seems more precise than an object keyed by message ID, which would also need to accept arbitrary keys. Though I'm curious if anyone knows another workaround. It does look cleaner to just allow nested message lists. Maybe barret knows?
Bug 1804480 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I think we don't want to use a plain array in place of a message definition object, because the local message corpus validation behavior should mirror the experiment message validation behavior as closely as possible, and the local message providers are top-level arrays, which apparently causes next-level arrays to be decoded as dictionaries (keyed by insertion index). Edit: Ignore the above, this was actually just caused by translation behavior that I missed, which I will fix. So I will go with plain arrays after all.