Skip to content

update Cargo.toml for release v2.6.0#1583

Merged
nikhilsinhaparseable merged 2 commits intoparseablehq:mainfrom
nikhilsinhaparseable:prepare-v2.6.0
Mar 15, 2026
Merged

update Cargo.toml for release v2.6.0#1583
nikhilsinhaparseable merged 2 commits intoparseablehq:mainfrom
nikhilsinhaparseable:prepare-v2.6.0

Conversation

@nikhilsinhaparseable
Copy link
Contributor

@nikhilsinhaparseable nikhilsinhaparseable commented Mar 15, 2026

Summary by CodeRabbit

  • Chores

    • Version bumped to 2.6.0
    • Updated package assets and metadata for the release
  • Bug Fixes

    • Timestamp parsing tightened: JSON numeric timestamp values are no longer accepted; only string representations are considered valid. This may affect ingestion and schema compatibility for systems sending timestamps as numbers.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Mar 15, 2026

Walkthrough

Bump package version to 2.6.0 and update parseable_ui asset metadata; tighten JSON compatibility check for Timestamp values to disallow numeric JSON numbers (accept strings only).

Changes

Cohort / File(s) Summary
Version and UI Assets Update
Cargo.toml
Bumped package version from 2.5.14 to 2.6.0 and updated parseable_ui assets-url/assets-sha1 metadata to the v2.6.0 values.
Timestamp JSON compatibility change
src/event/format/mod.rs
Value compatibility logic for Timestamp target types now treats JSON Number values as incompatible (previously considered compatible); only string representations are accepted for Timestamp.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Possibly related PRs

Suggested reviewers

  • nitisht

Poem

🐰 I nibbled code and found a tweak,
Versions hopped and hashes speak,
Timestamps now prefer strings to chew,
A gentle change — concise and true,
Hooray, the release hops anew! 🥕

🚥 Pre-merge checks | ✅ 2 | ❌ 1

❌ Failed checks (1 warning)

Check name Status Explanation Resolution
Description check ⚠️ Warning The pull request has no description provided, leaving required template sections (Description, testing checklist, documentation) completely unfilled. Add a detailed description explaining the release changes, confirm testing of log ingestion/query, and document any behavioral changes like the Timestamp JSON number compatibility modification.
✅ Passed checks (2 passed)
Check name Status Explanation
Title check ✅ Passed The title accurately describes the main change: updating Cargo.toml for a release version bump to v2.6.0, which aligns with the primary file modification shown in the summary.
Docstring Coverage ✅ Passed Docstring coverage is 100.00% which is sufficient. The required threshold is 80.00%.

✏️ Tip: You can configure your own custom pre-merge checks in the settings.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment
📝 Coding Plan
  • Generate coding plan for human review comments

Comment @coderabbitai help to get the list of available commands and usage tips.

coderabbitai[bot]
coderabbitai bot previously approved these changes Mar 15, 2026
nitisht
nitisht previously approved these changes Mar 15, 2026
…tection

Arrow's JSON decoder with coerce_primitive(false) cannot decode a JSON number
(e.g., 1773595502.7462175) into a Timestamp field.
it expects a string like "2026-03-15T17:13:59Z"

this fixes the rejection when two log sources send same field -
one as timestamp other as float number
Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@src/event/format/mod.rs`:
- Around line 437-440: The comment near the Value::Number match arm incorrectly
asserts Arrow's JSON decoder rejects numeric JSON for Timestamp fields; update
the comment in src/event/format/mod.rs next to the Value::Number => false and
surrounding match logic to either remove the Arrow-specific claim or explicitly
state this is a Parseable-specific restriction (not an Arrow limitation).
Preserve the intended behavior if keeping the restriction, but change the
wording to reference our Parseable policy (or delete the inaccurate Arrow
reference) so the comment no longer misattributes behavior to Arrow's JSON
decoder.

ℹ️ Review info
⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 497ef8df-3abd-498d-9488-d2c62c53dee0

📥 Commits

Reviewing files that changed from the base of the PR and between c925f7a and 3bf1dc4.

📒 Files selected for processing (1)
  • src/event/format/mod.rs

@nikhilsinhaparseable nikhilsinhaparseable merged commit fd9b9a4 into parseablehq:main Mar 15, 2026
12 checks passed
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