Skip to content

Add OpenCode Go (Lite) provider#484

Open
velazcod wants to merge 3 commits intosteipete:mainfrom
velazcod:main
Open

Add OpenCode Go (Lite) provider#484
velazcod wants to merge 3 commits intosteipete:mainfrom
velazcod:main

Conversation

@velazcod
Copy link

@velazcod velazcod commented Mar 5, 2026

codexbar_opencode_go

Copy link

@chatgpt-codex-connector chatgpt-codex-connector bot left a comment

Choose a reason for hiding this comment

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

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: a64ba1932d

ℹ️ About Codex in GitHub

Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you

  • Open a pull request for review
  • Mark a draft as ready
  • Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".

Comment on lines +584 to +586
let formatter = ISO8601DateFormatter()
formatter.formatOptions = [.withInternetDateTime, .withFractionalSeconds]
if let parsed = formatter.date(from: string) {

Choose a reason for hiding this comment

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

P2 Badge Accept resetAt timestamps without fractional seconds

This parser only configures ISO8601DateFormatter with .withFractionalSeconds, so common RFC3339 values like 2026-03-05T14:22:00Z fail to parse. In that case parseWindow falls back to resetInSec ?? 0, which makes the usage windows look like they reset immediately even though the API returned a valid reset time. Supporting both fractional and non-fractional ISO8601 forms avoids incorrect reset displays.

Useful? React with 👍 / 👎.

Copy link
Collaborator

Choose a reason for hiding this comment

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

@velazcod can you address this please?

@ratulsarna
Copy link
Collaborator

Thanks for the PR @velazcod !

A couple comments apart from the one codex pointed out:

  1. Worth double-checking the fallback behavior in parseWindow: on resetAt parse failure, defaulting to 0 is pretty risky because it silently produces incorrect reset UI instead of surfacing bad data.
  2. Because this PR adds 3-window usage fetching, one timestamp parsing issue can break rolling/weekly/monthly reset displays at the same time. I’d add tests covering all three windows with both ...00Z and ...00.123Z formats.

@velazcod
Copy link
Author

Yeah all good points. TAL

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants