Review 0.3.0 session closes immediately with "Ops" — works fine on 0.2.1 Body:

General
,
1

Hi,

After upgrading Review addon from 0.2.1 to 0.3.0, every review session closes immediately with “Ops”. Downgrading back to 0.2.1 works perfectly with the same versions and representations.

Server logs show:

text

review-0-3-0.sync.client | Client in a review session (Sync disabled)
review-0-3-0.sync.client | Client left the review session

Session joins then immediately leaves. Same Sync disabled log appears on 0.2.1 but stays open there.

Environment:

  • AYON Server: 1.14.3+202603101719
  • Review 0.3.0 — fails
  • Review 0.2.1 — works fine
  • Same published versions with valid MP4 review representations tested on both

Steps to reproduce:

  1. Switch bundle to Review 0.3.0
  2. Right-click any version with a review representation → Create Review Session
  3. Session opens briefly → “Ops” → closes immediately

Is this a known issue with 0.3.0?

2

Update after further investigation:

I did a deeper analysis of the browser console logs and network traffic and found the root cause.

The issue is a fatal frontend React crash in 0.3.0:

Error: useGlobalContext must be used within a GlobalProvider

This happens immediately after the WebSocket connects and the license check passes. The GlobalProvider (or equivalent) appears to be missing from the Review 0.3.0 component tree, causing the entire app to crash before rendering.

Additional findings:

  • :white_check_mark: License check for review: passing
  • :white_check_mark: License check for powerpack: passing
  • :white_check_mark: Backend GraphQL queries returning 200 OK with valid data
  • :x: WebSocket warning: [review] Unknown WebSockets topic: {..., topic: joined} — possible protocol mismatch between server and 0.3.0 client
  • The Client left the review session in server logs is a consequence of the frontend crash closing the WebSocket, not a backend issue

Environment:

  • AYON Server: 1.14.3+202603101719
  • Review 0.3.0 — crashes immediately
  • Review 0.2.1 — works perfectly

This seems like a regression introduced in 0.3.0 where a dependency on a shared AYON frontend library (possibly @ynput/ayon-react-components) expects a provider that isn’t initialized in the 0.3.0 app tree. A fix in 0.3.1 would resolve it.

3

Hi, are you trying to access the review session through an unsecure http connection?

4

Thanks, that fixed it! Accessing via https://domain through nginx works perfectly.

One follow-up question — is there any way to make Review 0.3.0 work over plain HTTP? We’re on a local network and getting the “not secure” browser warning since we’re using a self-signed certificate. Is there a configuration option to allow ws:// instead of wss://, or is HTTPS strictly required for 0.3.0?

5

We’re currently experiencing issues with the new Reviewable plugin version 0.3.0 in the Chrome browser. Specifically, the review session crashes immediately after opening.

I attempted clearing the browser cache, but this did not resolve the issue. However, I noticed that switching the URL from HTTP to HTTPS prevents the crash. This leads me to believe the issue may be related to protocol handling.

Following this, I attempted to configure Ayon to run over HTTPS. I referred to the forum guide Ayon nginx setup configuration - #3 by BigRoy , and I do have a valid SSL certificate installed on the server along with updates to the nginx.conf file. Unfortunately, I haven’t been able to get this working successfully. Additionally, the Ayon Launcher does not seem to function when using HTTPS.

Could you please confirm:
Whether it is currently supported to run Ayon fully over HTTPS (including the Launcher)?
If so, is there any official documentation or step-by-step guide available for configuring HTTPS properly?
Are there any known limitations or additional steps required for local Reviewable workflows over HTTPS?

This is quite important for our team, as we rely on Reviewable for inhouse workflows and the cloud is not possible at that moment for the studio.

6

Can you try the latest server release? (assuming you’re not on 1.14.6 yet?)

7

production version of 1.14.6 is not released yet I guess! we facing the same issue with 1.14.5

9

hello, i am on the latest version of the server 1.14.3+202603101719.

10

yeah i saw your post we are facing the same problem for the launcher as it doesn’t open https, but from my search that we need to download the certificate put it in path enviro and i think ayon will trust it i don’t know really still trying.

11

1.14.5+202603301343

This is the latest server @Youssef_M_ElQadi , make sure you pull the latest image

12

okay thank you, but i think that won’t solve the main issue though

13

the new review addon is released which supports http, but for anyone wondering later and if anyone wants to use https, you need to make the certificate first of all at the server then you copy it and open in the launcher that path “C:\Program Files\Ynput\AYON 1.4.3\dependencies\certifi\cacert.pem” for example then append the new certificate with start and end certificate to this i made a script that do that automatic using the shim to go for the latest launcher automaticly but you can do at every launcher or automate it anyways that what worked for me and the certificate ofc you should push it to the domain so the website read it as safe when it try to do a connection.

14

check this it might help

15

This seems like a separate post.
It’d be great if you could share us your steps for how you made https work for you Community Guides - Ynput community

16

sure thing will put it later :heart:

17

Coming back to this thread because the same crash is still present on current versions, and I now have a more precise root cause than what I posted in March.

Still reproducible on:

  • AYON server 1.16.0+202607241808 (build 20260724-1808, frontend commit 53dfa1aba, backend commit 16b514a7)
  • Review addon 0.7.1
  • Chrome, desktop

So this was never a 0.3.0 regression that later got fixed. It is still the behaviour now.

Same symptom as before, the review page dies with “Oops” and the console shows:

Error: useGlobalContext must be used within a GlobalProvider

What I can now confirm is the actual mechanism. I compared the exact same server through two access paths in the same browser, one over http on a LAN IP and one over https through our domain. Same server, same bundle, same project.

Over http on a LAN IP, window.isSecureContext is false, so Chrome withholds all of these:

  • crypto.subtle
  • crypto.randomUUID
  • navigator.locks
  • navigator.storage
  • serviceWorker

Over https all five are available.

The Review addon’s sync chunk (global-.js) references crypto.randomUUID, crypto.subtle, isSecureContext and navigator.storage. Over https that chunk initialises and logs “[sync] initial unsynced join”. Over http it never initialises at all, so GlobalProvider is never mounted, the component calling useGlobalContext throws, and the error boundary renders the generic “Oops”.

That also answers, negatively, the question I asked earlier in this thread about allowing ws instead of wss. It is not a WebSocket problem. The WebSocket connects fine over http and the license check passes. The blocker is the secure-context-gated crypto APIs, so no transport setting can work around it.

Worth flagging one red herring, since it cost me time twice. This warning:

[ Federation Runtime ] Version 1.18.17 from host of shared singleton module ynput/ayon-react-components does not satisfy the requirement of review which needs 1.18.16

appears on the working https instance too, so it is unrelated noise. It looks like a smoking gun but it is not.

A few questions:

  1. Is the secure-context requirement intended to be permanent for Review? If so, could it be stated in the addon requirements or docs? Any studio reaching the server by LAN IP over http will hit this immediately.

  2. Could the addon check window.isSecureContext at mount and render an explicit message, something like “Review requires a secure https connection”, instead of the generic “Oops”? The current error points you towards version mismatches and network problems, which is exactly where I lost time in March and again now.

  3. Is a degraded mode feasible on an insecure origin, for example playback and comments without the collaborative sync layer, or is the crypto dependency too deep for that to be practical?

18

Thank you @Youssef_M_ElQadi for spending the time to debug the issue and the detailed breakdown.

I can’t say we will ever support http as it is very insecure.

However, we can update the docs to state that https is required and we can add a better error message.

19

Thanks for the quick reply, and no worries at all. Chrome gating those crypto APIs behind a secure context is completely reasonable, and I wouldn’t want Review weakening that.

The friction is really on the self-hosted side. A lot of studios (us included) reach the AYON server by LAN IP over http, where there’s no public domain to hang a trusted certificate on, so https isn’t just a checkbox — it means running an internal cert somehow. So rather than “http vs https,” my real question is whether there’s a recommended way to run a self-hosted server over https on a LAN, so we get both the security and a working Review. If the team has a blessed path — a reverse proxy in front of the server, a self-signed/mkcert setup, or guidance on trusting an internal CA — pointing to that in the docs alongside the “https required” note would solve this cleanly for anyone in the same spot.

The docs update and the explicit “Review requires a secure https connection” message both sound great.

And if it’s ever cheap to answer: is a degraded mode on an insecure origin feasible (playback and comments without the sync layer), or is the crypto dependency too deep for that to be worth it? Totally fine if the answer is “not worth it” — just closing the loop on my earlier question.

20

A lot of studios (us included) reach the AYON server by LAN IP over http,

I thought you are on https already.

21

We may be looking at changing how we play the media in some time as well, and we’ve noticed that some of the changes we’d like to do may also require secure connection. As such, it’s very likely that the secure connection will only become more and more important with the review addon over time. It’s not fully decided though, but there’s definitely more reasons than just the sync.