syed owais

Hi! I’d like to work on this issue. The core problem is that the parser is evaluating the numeric literal before applying the sign, so -9223372036854775808 is first parsed as...

Thanks for the guidance! Adding support for signed integers directly in the lexer makes sense — especially since it keeps the parsing logic simpler and avoids the premature overflow that...

Hi! @joe-elliott I'd like to work on this issue. I'm still exploring the Tempo metrics pipeline code and understanding how metric arithmetic is currently handled, but I would love to...

Thanks for the update, and I really appreciate the context! Since this feature touches the parser, planner, and execution engine for TraceQL Metrics, I’d love to get some initial architectural...

Hi! I’ve been looking into this enhancement and I’d like to work on it. To make sure I’m aligned with the intended direction, here is my understanding of the problem...

Hi maintainers! @joe-elliott This PR fixes issue #4623 regarding correct parsing of math.MinInt64. All local tests pass. Please let me know if any changes are needed!

> So this is quite a lot of complex code for such an intense edge case. Tests should keep it together, but we still need to weigh the value of...

Thanks for the review, @joe-elliott implementing `minInt` / `maxInt` directly in the parser makes complete sense. It keeps the lexer simpler and aligns better with how other literals are handled...

Thanks for the review @joe-elliott! I’ve updated the PR with the requested changes. The constant handling for `minInt` and `maxInt` is now implemented cleanly in the parser, directly inside the...

@joe-elliott I’ve moved the minInt/maxInt handling into the parser and removed the redundant lexer logic. The branch is now rebased and ready for another look.