Second attempt, this time just hiding the cancel button when the upload is done. If user is impatient and refreshed in between this and `notify`, it will still be resumable later.
Bumped MINIMUM_VERSION to nudge for a refresh so we get a slightly more accurate logging, and also to prevent the issue from lingering.
## Steps
When it upload reaches 100%, click Cancel (not refresh).
## Issue
There was an old hack in b0509bc9 where we decided to wait a while before sending `notify` as the server was not responsive. Since the task was dispatched before the Cancel action, the server cleared the upload first and later received the `notify`.
## Change
Instead of trying to cancel the timer, I think the hack is no longer needed given the throughput and lock fixes. With things running back in sequential mode, the Cancel button will now just show the "upload already completed" modal.
## Ticket
1329
The existing nudge to refresh the webpage only happens when the app cannot find the specific javascript file in the server. As we don't purge the files on each build, the browser typically uses the cached version of the app, which could be weeks behind (based on the error logs).
## Approach
Poll the current version periodically (set to 1 hour for now) and invoke the nudge when a newer version is detected.
We typically don't need to bump `MINIMUM_VERSION` unless there is an urgent need to make users move away from older versions (e.g. API changes, mistakes, etc.)
## Trade-offs
Wanted to put the value in a separate file called `.min.version` so that the env's history won't be polluted with version bumps, but not sure how to implement with minimal code without having to read from the file. Getting from the env is the easiest to implement (per my limited knowledge).
## Ticket
725
## Issue
Upload a video. When `notify` is sent at the end of the tus upload, refresh immediately. The GUI allowed the user to resume the upload, but the ID is no longer present in the server.
## Approach
Until the polling API for `notify` is available, we can only assume the best and let the user know how to handle it.
- Store the "notify was sent" state.
- Show a dialog explaining the situation.
Thought of trying to make `claim_list` calls behind the scenes to clear itself, but it doesn't handle the case of `notify` actually failing. The best is to just let the user handle it for now.
Note that for the case of `onerror` actually received, we still retry since a network error could be the culprit (`notify` wasn't sent).
It was previously reduced to 10MB (d1447083) with the assumption that the slow disk write was causing the "lock" issue.
Now that the backend has implemented a new locking mechanism, restore to a larger chunk to reduce the number of PATCH calls.
```
10MB -> 2s/call
25MB -> 6s/call (similar to what I see with Google Drive)
100MB -> 25s/call
```
- Previously, we tried to solve the "file locked" problem by only making one retry after a super long delay. This was from an anecdote that it's more likely to lock up if the delay was short.
- This didn't help at all for our case, and Andrey has made some locking mechanism changes in the backend.
- The reduced number of retries probably increased the number of "failed to upload chunk" errors (not sure), which is supposedly a normal occurrence and we're expected to keep retrying.
Restoring the retry behavior and monitor...
And function name - was confusing that we had 2 with different paths.
Use 1280x720 to improve caching (used on mobile/tablets). There's no real spec for size.
I previously hardcoded both IDs since the script was not looking the right one at one point, but I guess that was unnecessary.
I don't think it causes any problems, because I'm still just loading 1 script (no double video, just 2 divs for them to choose).
Note that we are still using the `filepage` script since the `homepage` one is not working.
We are asking Outbrain to make it order-agnostic, but for now, we need to load the Sticky script first before the Banner script.
This is ugly code because the requirement is not obvious unless we put a bunch of comments, but I don't want to pollute `app/view.jsx`. Hopefully they can address this and we can revert in the coming days.
* Add cookie spaceman to gdpr banner
* Add spaceman graphic to static
* Add graphic to STATIC_ASSET_PATHS
* Add cookie spaceman to gdpr banner
* Add spaceman graphic to static
* Add graphic to STATIC_ASSET_PATHS
* Hide spaceman on mobile
* Adjust gdpr container for medium screens
## Issue
Due the `parseUri` not being used in a try-catch block, the thrown error surfaces all the way up and the 500 catch-all status was used.
The search console was been complaining about this for a while now. I've always thought "what's the problem here, you entered the wrong claim format", but now I realized it's about the error code.
## Change
`try-catch` the call as normal for that function, and return 404. We will still relay the error message it was.
## Issue
- When `/$/download/:claimname/:claimId` is invalid, it results in a bad redirect loop that keeps requesting the same thing. Eventually it stops, though.
- When `/$/stream/:claimname/:claimId` is invalid, it results in a 302 page that simply says `Redirecting to .`, and is increasing in count in the search console.
## Fix
Return a 404 not found for these.
* GoogleVideo: add more metadata
* GoogleVideo: fix `contentUrl`
`contentUrl` needs to be the url of the video file itself, not the page or some redirect. Copied the way the url is generated in the RSS code.
* Fix adnim ads
* Adjust ad container width
* Change widget on mobile
* Fix 3 column grid
* Ad ad banner top bar
* Ad ad banner bottom bar on mobile
* Ad ad banner bottom bar radius on mobile
* Adjust ad banners on mobile
* Make some mobile adjustments
* Remove dbeug box
* Combine ad classes
## Issue
Stickly loads fine when Category Page is opened directly (F5, open), but doesn't load if F5 was at Homepage and then navigated into Category Page.
## Root
There is a bug where AdsSticky cannot be loaded on a page where AdsBanner exists. As long as AdsSticky is loaded in a page without AdsBanner, they both can still be visible together later, says from navigating around.
## Temp fix
Adding inAllowedPath to the logic is a band-aid that relies on AdsBanner only being used in Homepage for now, which we currently happen to not place AdsSticky.
## Ticket
1583: "add incontent ads to category/channel pages (break up every X claims?), or add back bottom ad in those areas."
## Behavioral changes
- Hide when in homepage (as currently we have ads between categories).
- Fix the light theme (it was transparent).
## Code changes
- While an Effect is the 'right' choice given that there is no jsx to mount, the need to prop-drill from the parent was getting a bit annoying, so converted to a Component instead.
- Remove the delay for Core Vitals avoidance for now -- seems to make the sticky less likely to serve an ad.
- Now that the membership state is correctly populated for incognito (see 9d830615), there is no more need to check for `isAuthenticated`.
Using that global variable was a bad idea. Stick to redux as the source of truth.
The flag is not listed for rehydration, so it will always start off as `undefined`, which is what we need anyways.
`undefined` indicates we haven't tested for ad-blockers, so we'll run the fetch and update the store with a true|false value.
It would be nice if the individual components can handle the remounting of the ad-script, but there is currently a need to synchronize the cleanup of the `window.OBR` object.
The quickest solution for now is to add a key at the parent side to synchronize the mount-unmounting. Not ideal -- revisit later.
- This increases the amount of ads, filling up the entire width. No more need to restrict with `max-width` ourself.
- Changed the ad-driver to top-right since the "Powered by Outbrain" text is now locked in bottom-right. Also made the container having a minimum height, as the method to "display the driver after ads are loaded" is not future proof -- it depends on the IDs being used by the ad. Reserving some space seems to be easiest, and it also reduces shifts as well.
## Behavior in homepage
- Mobile: show after every other category
- Desktop: show after first category, then every 2 categories.
## Known issue:
- "FYP" is not part of the categories array at the moment, so it does mess up the behavior.
## Notes
I think this is also called "in-content" by adnim (not 100% sure of the terminology).
## Ticket
1572
Always check for availability before use.
## Changes
- Consolidated the keys into one place for easier tracking.
- It'll also be easier to code using constant autocomplete.
- Cleaned up the wrapper to be as close as the original.
- Updated existing code to use the wrapper (even if they already handled the availability) to encourage future code to just use the wrapper.
1. Hardcoding breaks any image changes done on dev instances or locally.
2. The relative path is bad, and there are few more instances of it. But continue as is for now, will file a ticket to fix this.
3. Fix caching.
This requires an accompanying commit in the homepages repo (see "Add announcement support").
Using `raw-loader` to import markdown files as a string works for the app-side, but didn't work well in web-side. Falling back to copying the announcement files to `dist` and reading them via `readFileSync`. Don't really like this -- will return with an alternative.
This reverts commit f6f15531d4.
The root-cause was known (8dd0982f), and I don't think it worked because:
1. The issue happened at the web side which didn't have logging.
2. The `[object Promise]` came after the `get`, not before.
