Fetching submissions #14

New issue

Open

opened 2026-04-15 23:22:44 +02:00 by maleszka · 1 comment

maleszka commented

2026-04-15 23:22:44 +02:00

Owner

We should maintain a list (cached on disk) of all user's submissions: (submitid, ContestNode.Ref, time, score, status, isfinal).

Having a complete list will allow us to:

get newest submit of contestnode -> so that we can fetch full results, e.g. after submit action
display last final submit status for each problem in fzf searches
calculate how many problems are solved in given subtree
provide nice submission statistics in wbij stats

PlatformAPI for downloading submissions should meet the following requirements:

we can get the newest submit with minimal number of queries (preferably only one)
we should get reasonably many submits for each query
we would like to have some guarantee that we've downloaded all submits

I would suggest the following endpoints:

    // Return highest node on path from `node' to root that can serve as a feed,
    // i.e. a node that PlatformAPI guarantees that can fetch all submissions of
    // nodes in its subtree in chronological order.
    //
    // This function should not make any network calls, as each platform should
    // be able to provide a hard-coded logic.
    pub fn getSubmissionFeed(
        self: Self,
        node: *const data.ContestNode,
        ancestors: []const data.ContestNode.Ref,
    ) data.ContestNode.Ref {}

    // Returns any non-zero number of Submissions from the specified feed that
    // have smaller submission time than `older_than'. If no such Submissions
    // are left, an empty slice is returned.
    pub fn fetchFeedSubmissions(
        self: Self,
        arena: std.mem.Allocator,
        feed: data.ContestNode.Ref,
        older_than: ?*const data.Submission,
    ) (error{ServerResourceDoesNotExist} || FetchError)![]const data.Submission {}

I believe these endpoints can be easily implemented for all competitive programming platforms; and they allow us to meet all the requirements, so I think this is a good design for now.

We should maintain a list (cached on disk) of all user's submissions: `(submitid, ContestNode.Ref, time, score, status, isfinal)`. Having a complete list will allow us to: - get newest submit of contestnode -> so that we can fetch full results, e.g. after submit action - display last final submit status for each problem in fzf searches - calculate how many problems are solved in given subtree - provide nice submission statistics in `wbij stats` PlatformAPI for downloading submissions should meet the following requirements: - we can get the newest submit with minimal number of queries (preferably only one) - we should get reasonably many submits for each query - we would like to have some guarantee that we've downloaded all submits I would suggest the following endpoints: ```zig // Return highest node on path from `node' to root that can serve as a feed, // i.e. a node that PlatformAPI guarantees that can fetch all submissions of // nodes in its subtree in chronological order. // // This function should not make any network calls, as each platform should // be able to provide a hard-coded logic. pub fn getSubmissionFeed( self: Self, node: *const data.ContestNode, ancestors: []const data.ContestNode.Ref, ) data.ContestNode.Ref {} // Returns any non-zero number of Submissions from the specified feed that // have smaller submission time than `older_than'. If no such Submissions // are left, an empty slice is returned. pub fn fetchFeedSubmissions( self: Self, arena: std.mem.Allocator, feed: data.ContestNode.Ref, older_than: ?*const data.Submission, ) (error{ServerResourceDoesNotExist} || FetchError)![]const data.Submission {} ``` I believe these endpoints can be easily implemented for all competitive programming platforms; and they allow us to meet all the requirements, so I think this is a good design for now.

maleszka referenced this issue

2026-04-16 00:13:14 +02:00

Updating local cache #10

maleszka referenced this issue

2026-04-18 11:46:04 +02:00

Updating local cache #10

maleszka commented

2026-04-22 02:18:54 +02:00

Author

Owner

Actually, I think the following endpoint would be better:

    // Returns all Submissions from the specified feed that were submitted after
    // the specified Submission. Submits are returned in chronological order
    // from oldest to youngest.
    pub fn fetchFeedSubmissions(
        self: Self,
        arena: std.mem.Allocator,
        feed: data.ContestNode.Ref,
        after_submit: ?*const data.Submission,
    ) (error{ServerResourceDoesNotExist} || FetchError)![]const data.Submission {}

The previous definition had this flaw that many platforms split submissions list across multiple pages, so PlatformAPI needs to know, on which page to look at in order to download specific time range. The presented solution solves this problem, although we may consider adding a std.progress.Node, cause the new definition can result in multiple queries now.

One of the motives behind the previous design was that it allowed to easily implement this idea of "get me one page of latest submissions". But that's more related to the question "how to update submissions list?" And that's a question that needs a separate consideration.

Actually, I think the following endpoint would be better: ```zig // Returns all Submissions from the specified feed that were submitted after // the specified Submission. Submits are returned in chronological order // from oldest to youngest. pub fn fetchFeedSubmissions( self: Self, arena: std.mem.Allocator, feed: data.ContestNode.Ref, after_submit: ?*const data.Submission, ) (error{ServerResourceDoesNotExist} || FetchError)![]const data.Submission {} ``` The previous definition had this flaw that many platforms split submissions list across multiple pages, so PlatformAPI needs to know, on which page to look at in order to download specific time range. The presented solution solves this problem, although we may consider adding a `std.progress.Node`, cause the new definition can result in multiple queries now. One of the motives behind the previous design was that it allowed to easily implement this idea of "get me one page of latest submissions". But that's more related to the question "how to update submissions list?" And that's a question that needs a separate consideration.