Copilot commented on code in PR #13955:
URL: https://github.com/apache/skywalking/pull/13955#discussion_r3619039719
##########
oap-server/analyzer/log-analyzer/src/test/resources/scripts/lal/test-lal/oap-cases/envoy-als.data.yaml:
##########
@@ -47,6 +47,29 @@ envoy-als:
abort: false
tag.response.flag: "upstream_connection_failure: true\n"
+# The envoy-als-tcp rule processes protobuf TCPAccessLogEntry as extraLog.
+# TCP entries have no HTTP status code; the rule filters on
+# commonProperties.responseFlags and tags the connection byte counts.
Review Comment:
The comment says the TCP rule "tags the connection byte counts", but the
envoy-als-tcp DSL only tags `response.flag` (responseFlags). This is misleading
for future maintenance of the data-driven cases.
##########
oap-server/analyzer/log-analyzer/src/main/java/org/apache/skywalking/oap/log/analyzer/v2/dsl/DSL.java:
##########
@@ -47,6 +47,15 @@ public class DSL {
@Getter
private final LalExpression expression;
private final FilterSpec filterSpec;
+ /**
+ * Effective proto input type this rule casts to, or {@code null} for
+ * parser-based / untyped rules (which run against any input). The runtime
+ * skips a rule whose declared type doesn't match the incoming log — this
+ * is how HTTP and TCP envoy access logs, which share {@code Layer.MESH},
+ * route to their own rules without cross-type {@code ClassCastException}.
+ */
+ @Getter
+ private final Class<?> inputType;
Review Comment:
`DSL#getInputType()` now returns the *effective* input type (null when a
parser is present), which differs from the declared/resolved input type coming
from YAML/SPI. Keeping the field/getter name as `inputType` makes it easy to
misread and accidentally use it as the declared type in future code; consider
renaming to `effectiveInputType` (and optionally retaining the declared type
separately if needed for debugging).
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
