Migrated events to openapi + autogenerated api client#729
Conversation
feat(events): generate main api client with orval
fix: migrate event mutations to generated hooks
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
lootlog-docs | 64b8c05 | Commit Preview URL Branch Preview URL |
Apr 12 2026, 03:52 AM |
|
Important Review skippedAuto reviews are disabled on base/target branches other than the default branch. Please check the settings in the CodeRabbit UI or the ⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 64b8c05a8d
ℹ️ About Codex in GitHub
Your team has set up Codex to 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 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| useListRankingEditHistory({ | ||
| guildId: guildId ?? "", | ||
| eventId: eventId ?? "", | ||
| rankingId: ranking.id, | ||
| enabled: historyOpen && ranking.pointsModified, | ||
| }); |
There was a problem hiding this comment.
Gate ranking history queries behind dialog state
useListRankingEditHistory is now executed unconditionally for every ranking row, so the page issues one /ranking/:id/history request per row on initial render (including rows with no edits and users without edit permissions). Before this change, the query was gated by historyOpen && ranking.pointsModified, which avoided a burst of unnecessary/forbidden requests; restoring that gate is important to prevent avoidable backend load and noisy 403s for read-only users.
Useful? React with 👍 / 👎.
| const { data: queryData } = useEventsMonitoringControllerGetHeroRespawnConfig( | ||
| { | ||
| guildId: guildId ?? "", | ||
| eventId, | ||
| heroId, |
There was a problem hiding this comment.
Avoid per-hero respawn-config fetches in badge component
This badge now calls useEventsMonitoringControllerGetHeroRespawnConfig per hero instance, and HeroCard renders one badge per hero, turning the event detail view into an N-request pattern (N = hero count). The previous implementation reused shared timers data and derived status locally, so this change can significantly increase request volume and page latency on events with many heroes.
Useful? React with 👍 / 👎.
Deploying lootlog-web-monorepo with
|
| Latest commit: |
fddc942
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2945c744.lootlog-web-monorepo.pages.dev |
| Branch Preview URL: | https://develop.lootlog-web-monorepo.pages.dev |
No description provided.