Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

fix: change cache busting mechanism on react to query string [DET-3325] #696

Merged
merged 1 commit into from
Jun 15, 2020
Merged

fix: change cache busting mechanism on react to query string [DET-3325] #696

merged 1 commit into from
Jun 15, 2020

Conversation

hkang1
Copy link
Contributor

@hkang1 hkang1 commented Jun 11, 2020 •
edited by jira bot
Loading

Description

The cache busting method currently used is not reliable across various browsers. The most reliable method discovered is using the query string to modify the URL, which modern browsers treat them as different file access, defeating cache. The basic idea is to attach a ts parameter with a timestamp attached to the URL the user is currently on and using window.location.href to load that page (essentially a reload with a ts query parameter.

Test Plan

Commentary (optional)

@cla-bot cla-bot bot added the cla-signed label Jun 11, 2020
@hkang1 hkang1 requested a review from hamidzr June 11, 2020 05:14
@hamidzr hamidzr assigned hkang1 and unassigned hamidzr Jun 11, 2020
@hkang1 hkang1 merged commit dadde23 into determined-ai:master Jun 15, 2020
@hkang1 hkang1 deleted the 3325-react-cache-busting branch June 15, 2020 19:26
@hkang1 hkang1 changed the title fix: change cache busting mechanism on react to query string fix: change cache busting mechanism on react to query string [DET-3325] Jun 15, 2020
tayritenour pushed a commit to tayritenour/determined that referenced this pull request Apr 25, 2023
@jerryharrow @dzhu
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (determ…
b071916 
…ined-ai#696)

With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
eecsliu pushed a commit to eecsliu/determined that referenced this pull request Jun 23, 2023
@jerryharrow @determined-ci
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (determ…
b68fff4 
…ined-ai#696)

With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
stoksc pushed a commit that referenced this pull request Jun 26, 2023
@jerryharrow @hanyucui
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
360438b 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
eecsliu pushed a commit that referenced this pull request Jun 28, 2023
@jerryharrow @NicholasBlaskey
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
f4ac8a9 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
eecsliu pushed a commit that referenced this pull request Jun 28, 2023
@jerryharrow @stoksc
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
3cbf48b 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
stoksc pushed a commit that referenced this pull request Jul 20, 2023
@jerryharrow @EmilyBonar
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
e7872b0 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
eecsliu pushed a commit that referenced this pull request Jul 24, 2023
@jerryharrow @eecsliu
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
a308143 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
stoksc pushed a commit that referenced this pull request Oct 17, 2023
@jerryharrow @NicholasBlaskey
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
762317e 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
azhou-determined pushed a commit that referenced this pull request Dec 7, 2023
@jerryharrow @azhou-determined
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
c40de8c 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
wes-turner pushed a commit that referenced this pull request Feb 2, 2024
@jerryharrow @determined-ci
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
e896820 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
@dannysauer dannysauer added this to the 0.12.10 milestone Feb 6, 2024
rb-determined-ai pushed a commit that referenced this pull request Feb 29, 2024
@jerryharrow @djanicekpach
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
3e772e3 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
amandavialva01 pushed a commit that referenced this pull request Mar 18, 2024
@jerryharrow @determined-ci
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
3b00eb1 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
eecsliu pushed a commit that referenced this pull request Apr 18, 2024
@jerryharrow @determined-ci
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (#696)
050951e 
With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
eecsliu pushed a commit to determined-ai/determined-release-testing that referenced this pull request Apr 22, 2024
@jerryharrow @eecsliu
fix: Revert back to LaunchAsync for Slurm jobs [FOUNDENG-465] (determ…
fb98f3e 
…ined-ai#696)

With synchronous launch the jobs is fully created (and potentially running)
before we get back the dispatchID and associate it with the allocation id.
If that happens we cannot associate the NotifyContainerRunning event with
the dispatch ID and we leave the container in PULLING state.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@hamidzr hamidzr hamidzr approved these changes

Assignees

@hkang1 hkang1

Labels
cla-signed
Projects
None yet
Milestone
0.12.10
Development

Successfully merging this pull request may close these issues.
3 participants
@hkang1 @hamidzr @dannysauer