Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Populate data_envelope with topic in json::decode() #443

Merged
merged 1 commit into from
Feb 22, 2025

Conversation

awelzel
Copy link
Contributor

@awelzel awelzel commented Jan 23, 2025

Hey @Neverlord - I'm attempting to use broker::format::json::v1::decode() to decode Zeek events sent by external clients, but implemented outside of the Broker layer. The Broker WebSocket format defines the "topic" a client publishes to, to be part of the top-level JSON object.

This PR changes decode() to optionally support extracting the topic, too. Does this feel too ad-hoc? I realize decode() can decode non-events, too, so maybe adding a separate helper would be the better approach?

It's this part from the internal/json_client.cc, but it has a parsed JSON representation available:

auto maybe_msg = data_envelope::deserialize(
id, endpoint_id::nil(), defaults::ttl,
caf::to_string(obj.value("topic").to_string()), buf.data(), buf.size());

@awelzel awelzel marked this pull request as draft January 23, 2025 10:08
@Neverlord
Copy link
Member

It definitely feels off to me to leak application logic into the decoding layer. What's wrong with asking the variant after decoding?

variant res;
... decode ...
if (auto topic = res.to_table()["topic"sv]; topic.is_string()) {
  ... topic.to_string() ...
}

@awelzel
Copy link
Contributor Author

awelzel commented Feb 15, 2025

What's wrong with asking the variant after decoding?

Have you tried? The json::data_message_to_binary() that converts from JSON to binary will discard topic of the top-level data-message. It only looks at the data and @data-type, so the resulting variant won't have that.

https://docs.zeek.org/projects/broker/en/current/web-socket.html#data-messages

It definitely feels off to me to leak application logic into the decoding layer.

So and so - the data-message as shown in the documentation does have a "topic" field, so maybe it's the name that's too generic.

@Neverlord
Copy link
Member

It only looks at the data and @data-Type, so the resulting variant won't have that.

Ah, that's the extra context that I needed. It's been a while, thanks for jogging my memory. 🙂

I do dislike the output parameter, though. What if instead of hard-coding topic::reserved as the topic, we take the topic from the JSON (if the field is present)? That would make it available in the envelope and you could navigate to it via variant::shared_envelope().

This allows users access to the topic via variant::shared_envelope()
@awelzel awelzel force-pushed the topic/awelzel/decode-top-level-topic branch from 4df0568 to 9bbdac5 Compare February 15, 2025 18:30
@awelzel awelzel changed the title RFC: Allow topic extraction via json::decode() Populate data_envelope with topic in json::decode() Feb 15, 2025
@awelzel
Copy link
Contributor Author

awelzel commented Feb 15, 2025

That would make it available in the envelope and you could navigate to it via variant::shared_envelope().

Yep, that works and looks nice! Re-pushed. Thanks!

@awelzel awelzel marked this pull request as ready for review February 16, 2025 17:12
@awelzel awelzel merged commit c99696a into master Feb 22, 2025
19 of 20 checks passed
@awelzel awelzel deleted the topic/awelzel/decode-top-level-topic branch February 22, 2025 20:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants