Merging the fixes takes a little time in order to make sure it doesn’t cause other issues and break more things than it fixes. I would estimate there’s about a week left of work (maybe a little more or less) before we can get a new icx-proxy out.
1 Like
Does this only affect icxproxy? I streaming form standard canisters xxxxxxxx.ic0.app affected?
1 Like
This bug should only impact icx-proxy/the raw subdomain. That said, I’m not sure the service-worker/non-raw currently supports streaming.
1 Like
Running the fixed build through final QA to (hopefully 
) deploy in the next couple days.
5 Likes
Just to be clear, this bug only affected users who used a custom Token type right?
Also, will dfx be updated with a new version to include this new icx-proxy? I believe they are now bundled together.
1 Like
A DFX update is also in the works. Note that advanced users can always replace the icx-proxy with the latest and greatest.
I think the current state of the bug impacts a wide variety of token/callback types, all of which should be resolved when this fix goes out. It more depends on what candid hacks the canister was using (now no hacks should be needed, but all hacks should be accepted).
The QA test went well, but Atlassian decided to blow up completely unrelatedly. While both our status page and ticketing system remains down, we are hesitant to deploy this.
Hopefully Atlassian is able to resolve their issues quickly.
3 Likes
any update on when we should expect this to be live
2 Likes
Based on Atlassian’s status updates, their restoration is progressing at a rate of about 5% per day. Assuming that remains constant, the expected value for our ticketing system restoration time is 6 days. But it is random, it could get restored tomorrow, it could get restored in 12 days, just depends on how lucky we get.
After the restoration it should be just a couple days to deploy.
Ouch! Not what I wanted to hear 
Update! Though Jira remains down, we have been able to mitigate and successfully deploy the fix. It should now be live and available! If you run into any issues, please report them here.
5 Likes
Thanks @Daniel-Bloom 
. Looks good, tested a 4mb jpg image with the same repo provided above locally and on mainnet (without any new deployment), the image was download and displayed entirely in both cases.
3 Likes
If we want this fixed on the local replica(dfx) what do we need to do?
1 Like
You are right I still have the issue locally to. I assumed it was alright because UI wise the image was alright but that was already the case with .jpg. To reproduce the issue I should have used .png 
.
@Daniel-Bloom what should we / I upgrade to test locally? dfx?
Hey @Daniel-Bloom I think this was deleted when the code was merged…where is it now? Is it easy to compile/replace on a local replica?
To use an updated icx-proxy with dfx locally before we’ve released a dfx version that incorporates it, you can do this:
- download an icx-proxy release from Releases · dfinity/icx-proxy · GitHub (extract
icx-proxyfrom either binaries-linux.tar.gz or binaries-macos.tar.gz) - export DFX_ICX_PROXY_PATH=
<path to icx-proxy> - run
dfx start
3 Likes
What directory would the current one be in? Would it be advisable to just overwrite what is there now to make sure we get an update in the future?
Edit: /Users/[user]/.cache/dfinity/versions/0.9.3/?
The current one will be in $(dfx cache show)/icx-proxy. Yes, you can overwrite the binary at that path instead, if you want.
1 Like
I think you can right-click “open”, and it will ask you to verify once that it’s ok. Or maybe it’s Option open.