Bug Reports

What we found: The event has a "Triggered when" entry. Opening it shows a card titled "Journey Trigger" with the text: "This trigger is connected to the following 1 journey:" — but no journey is actually listed below that text. Clicking into the trigger's detail view (Trigger 1 of 1) shows "No journey steps connected / This trigger hasn't been connected to any journey steps yet." The workspace's Journeys page shows "Journeys (0)" — there are zero journeys documented. Via the Avo MCP integration, get(type:"event", id:"<EVENT_NAME>") returns this same trigger with an additional property condition not visible in bullets 1–2 above in the UI text we captured (a property equality condition on one of the event's properties). Calling list_journeys via MCP for this workspace returns "Journey read is coming soon for this workspace." Why this is confusing / likely a bug: The trigger is explicitly labeled "Journey Trigger" and claims to be connected to 1 journey, but that journey does not exist anywhere in the workspace (0 journeys total) and the trigger's own detail view confirms no journey steps are connected. This orphaned/ghost reference makes it impossible for anyone auditing the event (or an integration like Avo MCP) to determine where this trigger's property condition actually originates from or how to edit/remove it — there's no property-condition field exposed for this trigger type on the event page itself, and no journey to trace it back to. Steps to reproduce: Open the affected event in the workspace referenced above. Under "Triggered when," open the existing trigger. Observe the "Journey Trigger" card claiming a connection to 1 journey, with none listed, and the canvas showing "No journey steps connected." Compare with the workspace's Journeys page (0 journeys) and/or the MCP list_journeys response ("coming soon"). Request: please clarify (a) where this trigger's property condition actually lives / how it can be edited or removed, and (b) why the trigger is labeled and behaves as a "Journey Trigger" pointing to a journey when the workspace has none. Screenshots attached.

In a new workspace, create a new event and see it appears twice in the UI. Is this a feature, if it is then it's confusing. If it's a bug, please fix it.

I see 4 open branches in the branches list. On the top it says "1 open". Also, when opening a branch is displays the "Merged" pill. E.g., branch universal-onboarding-events

Code generation VERSION 183.8.0 incorrectly flattens nested product properties in the debugger section I see a mismatch between dashboard schema vs. generated code Impact: The Avo UI debugger shows empty fields that shouldn't exist at the top level. This is not impacting anything but it is confusing. Just wanted a confirmation from your side so that we don't spend more time on this. Thank you! Note: In the 1st and 2nd screenshot, you can see the definition of the event in the Avo Dashboard. In the 3rd screenshot, you can see that the fields showing up as top level fields in the Avo debugger are incorrect and they shouldn't be there. I checked in the codegen file and I can confirm the additional fields are present - proving that codegen probably is incorrectly generating these fields.

We introduced a new version of an event which now has an additional required property. It has a new Snowplow version attached and only for this version, the property is required. However in Inspector, there are errors for this event when sent from with the old schema version that doesn't require the property.

I was debugging a problem where we had events marked as correctly sent in the visual debugger as well as in the console. As you can see on the screenshots, I get a validation for "Checkout step started". However, the event was never correctly sent via the Snowplow Interface because of an timing issue, where the Interface wasn't initialized fast enough before the first event. The code in Avo.ts first logs the event as sent correctly, before actually trying to send it via trackSelfDescribingEvent . This should be handled differently, so we can be sure, that a event was actually successful.

Just apply a source filter (maybe other filters too). If there is a category that doesn't have events when those filters are applied, it still shows up but empty. I feel like this didn't used to do this but now does. I could be misremembering and this should be a feature request instead. https://therighttrack.slack.com/archives/C02EZ7VU0MA/p1733465092329489

Create a category. Create a second category with a different name. Rename one of those categories to the same name as the other. There is no block on this.

Event properties set to 'always send' are changed to 'sometimes send' after merging to "main" branch. It's an issue as it publishes the taxonomy to Snowplow with the wrong settings.