parse span path as array

[dinmukhamedm]

Important

Change span path handling from strings to arrays, updating related functions to support this new structure.

• Behavior:
  • Change span path representation from String to Vec<String> in SpanAttributes.
  • Introduce flat_path() in SpanAttributes to convert path arrays to dot-separated strings.
• Functions:
  • Update CHSpan::from_db_span() in ch/spans.rs to use flat_path().
  • Modify inner_process_queue_spans() in consumer.rs to use flat_path().
  • Update create_datapoint() in index.rs to handle path as array.
  • Change extend_span_path() in SpanAttributes to append to path arrays.
• Misc:
  • Remove unused import serde_json::Value in index.rs.

^{This description was created by for 6709106. It will automatically update as commits are pushed.}

[ellipsis-dev]

👍 Looks good to me! Reviewed everything up to 6709106 in 1 minute and 29 seconds

More details

• Looked at 136 lines of code in 4 files
• Skipped 0 files when reviewing.
• Skipped posting 2 drafted comments based on config settings.

1. app-server/src/traces/index.rs:85

• Draft comment:
  Using v.to_string() on a serde_json::Value may not produce the expected string representation for non-string JSON values. Consider using a more robust method to convert JSON values to strings, such as json_value_to_string.
• Reason this comment was not posted:
  Decided after close inspection that this draft comment was likely wrong and/or not actionable:
  The comment raises a valid technical point - to_string() on a JSON Value will give different results for different types. For a string it removes quotes, for objects/arrays it includes them. However, this is in the context of semantic search indexing where the path is an optional field. The previous code was actually more restrictive by only allowing string values.
  The new code is actually more flexible by accepting any JSON value type. Maybe this flexibility is intentional and desired for the semantic search use case?
  While the comment is technically correct about to_string() behavior, the change appears intentional to support more value types, and the string representation is only used for semantic search indexing where exact format may not be critical.
  The comment should be deleted as it appears to be questioning an intentional change that makes the code more flexible, and there's no strong evidence that the new behavior is problematic for this use case.

2. app-server/src/traces/consumer.rs:247

• Draft comment:
  Using unwrap_or_default() on flat_path() returns an empty string if the path is None. Ensure this is the intended behavior, as it might be better to use a specific default value instead.
• Reason this comment was not posted:
  Confidence changes required: 50%
  The unwrap_or_default() method is used on the result of flat_path(), which returns an empty string if the path is None. This might not be the intended behavior if a default value is expected instead of an empty string.

Workflow ID: wflow_YgTd1d2H4JB51eKm

---

You can customize Ellipsis with 👍 / 👎 feedback, review rules, user-specific overrides, quiet mode, and more.