Hello GitHub Support,
We are conducting a strictly read-only technical review of the open-source Supabase Studio repository as part of a production safety assessment.
Repository: https://github.com/supabase/supabase
Our objective is to establish which source-code components and revisions govern the current Explorer → Logs interface, particularly its date picker and query execution path.
We would appreciate your guidance on the following questions.
What is the best way to locate the actual date-picker component used by Explorer → Logs?
How can we trace its imports, function calls and related date utilities across the repository?
Can GitHub Code Search help identify whether startOfDay, endOfDay or equivalent timezone conversion functions are used in this execution path?
How can we identify the exact commit that introduced the new Explorer → Logs interface?
How can we determine which subsequent commits modified its date-picker or query execution logic?
Is there a reliable GitHub-supported way to compare the relevant files across commits or releases?
Can GitHub identify the source revision deployed by a third-party service, or would that require confirmation from Supabase?
We want to establish whether the relevant source code supports selecting an absolute UTC interval of exactly one hour, for example:
Start: 2026-10-15T10:00:00Z
End: 2026-10-15T11:00:00Z
How can we trace the transformation from the selected date range to the final serialized request parameters?
How can we identify whether the frontend expands the interval to local calendar-day boundaries?
Is there a way to verify these transformations using repository inspection alone, without running the application or making production requests?
Our preliminary source review indicates that the new Explorer uses a mutation-based execution path.
How can we trace whether this path contains automatic retries, refetching or other implicit execution triggers?
Can GitHub's code-navigation and history tools help distinguish the new Explorer's execution path from the legacy implementation?
What source-level evidence would be needed to support a conclusion that a user action results in one client request?
We understand that source inspection alone cannot guarantee the number of backend executions.
Which GitHub features would you recommend for this type of source-code investigation?
Can GitHub Support assist with repository history and code-navigation questions for a public third-party project?
Which questions should instead be directed to Supabase maintainers?
Safety constraints
We are not requesting any production access, SQL execution, log queries, deployment, configuration changes or testing against a live Supabase project.
We only want guidance on public repository inspection and commit-history verification.
If these questions are outside GitHub Support's scope, please direct us to the appropriate GitHub functionality or public maintainer discussion channel.
Thank you for your assistance.
Best regards, VelloBoka Team
The user is conducting a technical review of the Supabase Studio open-source repository. They seek guidance on identifying source code components and revisions related to the Explorer → Logs interface, particularly the date-picker and query execution path. They ask about using GitHub tools for source-code identification, commit verification, and understanding UTC handling without running the application.
You are not likely to reach Supabase on this topic thru discussions. Maybe an issue in that repository. You could try support but not clear they will take this up either. You mainly get other users here in discussions.