Skip to content

Preserve JVM default timezone when generating tenant tokens - #1003

Open
suryakant-source wants to merge 2 commits into
meilisearch:mainfrom
suryakant-source:patch-1
Open

suryakant-source wants to merge 2 commits into
meilisearch:mainfrom
suryakant-source:patch-1

Conversation

@suryakant-source

@suryakant-source suryakant-source commented Oct 23, 2026 •

Copy link
Copy Markdown

Fixes #1002

Remove the global TimeZone.setDefault call from generateTenantToken. Expiration validation compares Date instants and JWT expiration is stored as epoch seconds, so generating a token does not need to change the host application's timezone.

Add two server-free regression tests that restore the original timezone in finally blocks:

  • successful generation preserves a non-UTC default, the expiration instant and API key UID;
  • rejection of an expired token also preserves the default timezone.

Validation with JDK 17:

  • Both new tests fail on the original implementation and pass after the fix.
  • ./gradlew test --tests '*TenantTokenTimezoneTest' -x jacocoTestCoverageVerification spotlessCheck passes. Coverage verification is excluded for this focused run because it checks whole-project coverage.
  • Full ./gradlew test runs 115 tests: 112 pass, with the same three SettingsHandlerTest connection failures observed before the fix (no local Meilisearch server). No server-backed integration run was performed.

AI assistance was used to prepare the fix and regression tests. The changes were reviewed and the checks above were run locally.

Summary by CodeRabbit

  • Bug Fixes
    • Generating tenant tokens no longer changes the JVM’s default time zone. Token expiration validation and generation continue to work as before, helping ensure token operations don’t affect time-zone settings used by other parts of the application.
    • Added coverage for token generation and expiration validation under non-UTC time zones, including checks that the default time zone remains unchanged.

Signed-off-by: Suryakant Sahoo <230859682+suryakant-source@users.noreply.github.com>
Signed-off-by: Suryakant Sahoo <230859682+suryakant-source@users.noreply.github.com>
@coderabbitai

coderabbitai Bot commented Oct 23, 2026 •

Copy link
Copy Markdown
Contributor

Review in Change Stack →

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info
⚙️ Run configuration
  • Source mode: Auto
  • Repository: Unavailable
  • Branch: Unavailable
  • File: No configuration file from this repository applied
  • Commit: Unavailable
  • Layers: Organization UI
  • Review profile: CHILL
  • Plan: Advanced
  • Run ID: 3b5cbf94-4102-4f31-8e45-64d000606b29
📥 Commits

Reviewing files that changed from the base of the PR and between 76c96b3 and 7f3f1e1.

📒 Files selected for processing: 2
  • src/main/java/com/meilisearch/sdk/Client.java
  • src/test/java/com/meilisearch/sdk/TenantTokenTimezoneTest.java
💤 Files with no reviewable changes: 1
  • src/main/java/com/meilisearch/sdk/Client.java

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

📝 Walkthrough

Tenant-token generation no longer changes the JVM-wide default timezone. New tests check timezone preservation during successful token generation and when expiration validation fails.

Changes: Tenant token timezone handling

Layer / File(s) Summary
Remove global timezone mutation and test preservation
src/main/java/com/meilisearch/sdk/Client.java, src/test/java/com/meilisearch/sdk/TenantTokenTimezoneTest.java
generateTenantToken no longer sets the default timezone to UTC. Tests verify that successful generation preserves the configured timezone and that epoch-zero expiration is rejected without changing it.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix · Severity of issue fixed: Medium

Suggested reviewers: alallema

Merge Risk: ⚪ Minimal · up to 7f3f1

The change is ready for normal merge checks; no actionable merge-blocking risk is identified.

Pre-merge checks: Passed 4 · Failed 1

Failed Failed checks: 1 warning

Check name Status Explanation Resolution
Docstring Coverage Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 1 files. Write docstrings for the functions missing them to satisfy the coverage threshold.
Passed Passed checks: 4 passed
Check name Status Explanation
Description Check Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check Passed The title "Preserve JVM default timezone when generating tenant tokens" matches the main change. The PR removes the global TimeZone.setDefault(UTC) call from Client.generateTenantToken, so the JVM def…
Linked Issues check Passed Issue #1002 requires removal of the global timezone mutation from Client.generateTenantToken. The whole-PR diff removes TimeZone.setDefault(TimeZone.getTimeZone("UTC")) and leaves expiration valid…
Out of Scope Changes check Passed The PR changes only Client.generateTenantToken and adds focused regression tests for issue #1002. The tests directly verify that the removed global side effect does not recur and that token behavior…
Full details: Title check

Explanation

The title "Preserve JVM default timezone when generating tenant tokens" matches the main change. The PR removes the global TimeZone.setDefault(UTC) call from Client.generateTenantToken, so the JVM default timezone is no longer changed. The title is specific, short, and states the primary behavior change from the developer's perspective. The changeset also adds a regression test class, which the title does not mention, but that is expected and does not reduce the title's accuracy.

Full details: Linked Issues check

Explanation

Issue #1002 requires removal of the global timezone mutation from Client.generateTenantToken. The whole-PR diff removes TimeZone.setDefault(TimeZone.getTimeZone("UTC")) and leaves expiration validation and token generation in place. TenantTokenTimezoneTest adds server-free coverage for successful generation and expired-token rejection under non-UTC defaults. The tests also verify token expiration and API-key UID for successful generation.

Full details: Out of Scope Changes check

Explanation

The PR changes only Client.generateTenantToken and adds focused regression tests for issue #1002. The tests directly verify that the removed global side effect does not recur and that token behavior remains correct. No unrelated production or test changes appear in the whole-PR diff.

✨ Finishing Touches
🧪 Generate unit tests (beta)
  • Create a new PR
  • Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

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

This branch has not been deployed

No deployments
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.

Client.generateTenantToken() permanently mutates JVM default timezone to UTC

1 participant