[BUG] Editing Queries Fails After [TBD?] for All 2sxc Queries - 2sxc 19.03.01

[jeremy-farrance]

Bug Affects...

[x] edit experience / UI
[x] admin experience UI

Current Behavior

After adding, editing and saving Visual Queries (which works at first), we add another new one filling out just the Query Name (we named it, "EDN Event Articles by Params", though I doubt that matters), clicked save, then clicked on the new Query's Name field to open the Visual Query editor in a new tab. The tab opens, the page is blank/white. Reloading the new tab makes no difference.

This is the error that appears in the Chrome DevTools/Console log - note that this is in the NEW TAB that opens for the Visual Query edit UI

Expected Behavior

We should be able to Edit Visual Queries like normal.

To Reproduce (Steps, Videos, Screenshots, Apps)

1. New DNN 9.13.07, install 2sxc 19.03.01 and get it working (CodeDom 3.6, etc.)
2. Install an existing app (we chose Blog) and get it on a page
3. Go to Admin, then the Queries (tab) UI
4. Click any query's name to Edit...

New tab opens, stays blank, error in Console of new tab

[jeremy-farrance]

I have to mention that this is really urgent for us, this is an in-development project and it would require quite a bit of effort to work around NOT being able to use the Visual Query Edit UI. I am available (contact me via Discord) if you have trouble reproducing this. Its happening on multiple projects now and easy to reproduce in a clean local install of DNN+2sxc.

[jeremy-farrance]

Additional weirdness - Please read, especially the item at the bottom!!

Once the problem happens and all attempts in any app to edit any existing Query fails, we tried the following to get it working again, all failed:

• Restarted DNN (app pool)
• Restarted the browser and also tried in a different browser (Edge and Firefox)

Weird way to get it working again... and then fail again (WTF?)

After it fails and you are ready to give up, try this:

• Install a new 2sxc App that you know has some Queries
• Get it on a page and working
• Go to App Admin, Queries, edit one of Queries, IT WORKS
• Now go back to the other App and try to edit one of the queries that failed before, it fails
• Now go back to your newly installed App, edit one of the Queries, NOW IT FAILS

[iJungleboy]

I need to know where the failure happens.

If a "broken" app is installed on another DNN, is it still broken? if yes, could you upload such an app to speed up testing?

[jeremy-farrance]

Just FYI, this continues to happen once or twice each work day here. No reproducible pattern. I've adjusted the steps above to eliminate some things that made no difference.

[jeremy-farrance]

Since we have this happening for two people on two different machines in 3 projects with any browser, I just want to recap the key observations.

• See screenshot above, the error that happens is while Angular (core js) is executing on the front end
• This is happening on real in-progress projects that started life with DNN v9.13.07 and 2sxc 18.6.1... then upgraded to 19.3.0 LTS then 19.3.1 LTS. The problem was first noticed after installing 19.3.1, these dev+staging projects run on remote (vps-style) servers in the cloud
• This is happening on clean+new deploys of DNN v9.13.07 and 2sxc 19.3.1 LTS, these projects are running locally on a Windows 11 machine
• We use CodeDom 4.1 (from DNN v10), but the problem happens with CodeDom 3.6, so I no longer think this is a factor
• Once the problem happens, it is no longer possible to edit any Visual Query in any app in this DNN instance.
• After it happens, if you come back ~4 hours later or the next day, usually, but not always, the problem has fixed itself
• This happens in any browser, any version (we are mostly using Chrome latest or latest-1)
• Deleting all cookies and browser data for the site (and logging in again) does not fix the problem (e.g. in Chrome, chrome://settings/content/all, search for the URL of your site, etc)

[jeremy-farrance]

Another un-scientific observation

If you go into DevTools, Console, Network tab and slow things down > set the Throttling down to 3G (or Slow 4G), the problem is MORE LIKELY to happen.

But then again, I also have the impression its more likely to happen in the morning than in the afternoon. :/

[jeremy-farrance]

Note: I don't do Angular at all, so I might be saying things (about modules or routes) that are wrong...

After a week of playing with this on and off and at different times, my general impression is that this is a timing issue. Something that normally (lazy) loads fast-enough is sometimes a little late (not there when needed) and (Angular?) routes fail.

When launching in to a new tab (/desktopmodules/tosic_sexycontent/dist/ng-edit/), was anything about the loading modules or routes changed recently? Maybe in relation to the newer ctrl-click feature that forces various front-end edit UIs in to a new tab?

[iJungleboy]

The timing thing could be a lead.

I don't think it's related to the open-link-in-new-window, because the query always opened in a new window. But we did refactor some services to use signals instead of Observables inside Angular.

It's possible that something wasn't done quite correctly. Maybe @paulpietzko could look at this next week?

[jeremy-farrance]

Tested again by upgrading a site from 2sxc 19.03.01 to v19.03.02. Same error. could not find any differences to what has been reported so far (above).

[jeremy-farrance]

After playing some more, I did get something new to happen. After the upgrade, the error happened immediately on the first Query I tried to edit. I tried a few more queries, all new tab > blank+error. Suspiscious of the "timing" issue I made note of the upgrade install happening at 10:01 am. I set a timer to try again after 20 mins. No diff, still broken.

Then, I set another timer to try again after 10:31am... and presto, it started working again; I could edit a Visual Query and everything was working like normal for all queries!! So almost exactly 30 mins after the install of the 2sxc upgrade, suddenly the Visual Queries are working completely normal again.

I hope this is somehow a helpful clue.

[paulpietzko]

@Dominikg77 is probably the better one to solve this.