Skip to content
This repository has been archived by the owner on Jul 31, 2020. It is now read-only.

previousFetchTime parameter for FETCH_SYNC_RECORDS #363

Merged
merged 3 commits into from
Jan 10, 2020

Conversation

AlexeyBarabash
Copy link
Contributor

Related brave-browser issue brave/brave-browser#7327 .
Related brave-core PR brave/brave-core#4231 .

@AlexeyBarabash
Copy link
Contributor Author

CI fails because needs rebase.

@AlexeyBarabash AlexeyBarabash force-pushed the poll_sqs_after24h branch 2 times, most recently from 7904db5 to 1310f20 Compare December 27, 2019 18:36
@AlexeyBarabash AlexeyBarabash marked this pull request as ready for review December 27, 2019 18:43
@@ -57,7 +57,7 @@ const messages = {
* with new records, do
* GET_EXISTING_OBJECTS -> RESOLVE_SYNC_RECORDS -> RESOLVED_SYNC_RECORDS
*/
FETCH_SYNC_RECORDS: _, /* @param Array.<string> categoryNames, @param {number} startAt (in seconds or milliseconds), @param {number=} maxRecords limit response to a given max number of records. set to 0 or falsey to not limit the response */
FETCH_SYNC_RECORDS: _, /* @param Array.<string> categoryNames, @param {number} startAt (in seconds or milliseconds), @param {number=} maxRecords limit response to a given max number of records. set to 0 or falsey to not limit the response, @param {number} previousFetchTime (in seconds or milliseconds) */
Copy link
Contributor

Choose a reason for hiding this comment

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

not specifying whether the value is seconds or milliseconds seems like a really bad idea to me, what is the reason for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bridiver , seconds or milliseconds as a requirement of output were introduced long time ago , 349592a#diff-e10a265c86f058932ac016e27462b9a5R54 , but we don't know what was the reason.

Copy link
Contributor

Choose a reason for hiding this comment

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

That's fine for existing params, but I don't think we should continue the practice for new ones. I think it's an extremely bad idea to pass a timestamp that doesn't specify one of the other

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bridiver addressed in c4a0e66

.gitignore Outdated
bundles/*.js
bundles/constants/*.js
Copy link
Contributor

@bridiver bridiver Jan 2, 2020

Choose a reason for hiding this comment

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

just fyi - you can do `bundles/**/*.js and that will cover all subdirectories (and the main directory) if that's what you want

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bridiver thanks, I didn't know that.
Modified according the notice in 847f24d , despite you already approved.

bridiver
bridiver previously approved these changes Jan 2, 2020
client/requestUtil.js Outdated Show resolved Hide resolved
test/client/requestUtil.js Outdated Show resolved Hide resolved
darkdh
darkdh previously approved these changes Jan 2, 2020
@AlexeyBarabash
Copy link
Contributor Author

Squashed some "fix" commits and done force push.

@AlexeyBarabash AlexeyBarabash merged commit dc64efe into staging Jan 10, 2020
AlexeyBarabash added a commit that referenced this pull request Jan 10, 2020
previousFetchTime parameter for FETCH_SYNC_RECORDS
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants