fix: add more conflict validation for tracing

[taloric]

No description provided.

[taloric]

@claude review PR

[claude]

Claude finished @taloric's task in 7m 26s —— View job

---

a. Event type and context: GENERAL_COMMENT on PR #402 in deepflowio/deepflow-app, triggered by `@claude review PR`. b. Request type: code review feedback only; no implementation requested. c. Key info: branch `add_conflict_validate`, PR title `fix: add more conflict validation for tracing`, one modified file `app/app/application/l7_flow_tracing.py`, base reference should be `origin/main`. d. Main tasks and challenges: inspect the new trace-id filtering logic, validate it against existing multi-trace behavior, and report any correctness issues with line references. e. High-level plan executed: reviewed repo instructions available in-tree, inspected the changed logic and surrounding tracing flow, and compared it with the existing `allow_multiple_trace_ids_in_tracing_result` behavior. f. Tooling note: direct `git diff origin/main...HEAD` required approval in this environment, so the review is based on the provided changed-file metadata plus the current file contents.

Todo

• Review repository instructions and PR context
• Inspect the tracing validation change in detail
• Write and post PR review feedback

Review

I found one correctness issue.

• Multi-trace mode is no longer respected in the trace_id query path at app/app/application/l7_flow_tracing.py:420-429.
  The new branch treats any row whose trace_id column splits to a single value not already in allowed_trace_ids as a conflict and drops it. That is correct for the default single-trace mode, but it also runs when allow_multiple_trace_ids_in_tracing_result is enabled. In that mode, the later non-trace_id path explicitly allows discovering additional trace IDs and queues them for the next iteration at app/app/application/l7_flow_tracing.py:572-578, and the config is documented for exactly that behavior in app/app.yaml:32-33.

  With this change, a FastFilter(trace_id) query that returns a legitimate neighboring flow containing exactly one new trace ID will now be discarded before it can be added to new_trace_ids_for_next_iteration, so multi-trace expansion becomes asymmetric depending on which path discovered the flow.

  Fix this →

Summary

The new false-positive filtering looks reasonable overall, but the single-trace conflict rule at app/app/application/l7_flow_tracing.py:426-429 appears to unintentionally block the documented multi-trace mode.