API Issues Only

Please note that this is a tracker for the SketchUp and LayOut APIs only.

Bugs or feature requests that do not relate to the APIs will be removed. Fill in as much details as possible.

Bug Reports

Please include the following:

SketchUp/LayOut Version: SketchUp 2024.0.533
OS Platform: Windows 11 Pro 64-Bit 22631.3380 (also seen in Windows 10 Pro 64-Bit 19045.4651)

Describe briefly what you are doing and what is happening.

When making a fetch request repeatedly in UI::HtmlDialog it will randomly hang. It doesn't matter which server I make requests to, the issue also occurs when using XHR / Axios to make requests.

This appears very similar to the issue reported #986 - it was closed but we are still seeing this problem with 24.0.533

Describe what the expected result is.

Valid fetch requests always complete successfully.

Steps to reproduce with code snippets

Launch a server on local host (express code given below, note that any local server will work really)

// node.js express server (though any will work)
const express = require('express')

const app = express();

app.get('/', (_request, response) => {
  response.send('test')
})

app.listen(3000, () => {
  console.log('Listening on port 3000')
})

Run the following HtmlDialog code in the Sketchup 2024 Ruby Console

# HTML Dialog
dialog = UI::HtmlDialog.new()
dialog.set_html(%{
  <!DOCTYPE html>
  <html lang="en">
    <body>
      <button onclick="loopRequests()">Begin</button>
    </body>
    <script>
      const loopRequests = async () => {
        while (true) {
          const res = await fetch("http://localhost:3000")
          const text = await res.text();
        }
      };
    </script>
  </html>
})
dialog.show

Open the chrome dev tools and go to network tab
click the "Begin" button in the HtmlDialog to begin the requests loop
note that eventually in the network tab the requests stop and the last one hangs
the network tab gives the following in the Timing tab for the the hanging request (it also shows nothing in the response tab):

Jul 26 '24 13:07 johnscollins98

@johnscollins98

I assume everything is fine if you run similar code in a browser?

Jul 26 '24 16:07 MSP-Greg

@MSP-Greg i haven't been able to reproduce the issue in a regular browser yet after tens of thousands of requests

In Su2024 it usually occurs within a few hundred requests tops

Jul 26 '24 17:07 johnscollins98

Also I can't reproduce it in other versions of Sketchup (2023, 2022, 2021 tested)

Jul 26 '24 17:07 johnscollins98

Interesting. This doesn't seem like the same issue as #986, as you've got a running loop and the failure happens after the loop has run several requests?

Have you tried debugging the response object to see if it shows anything? 'Stalled' is a bit vague...

I've written a lot of Ruby code running at a socket level, but I can't do that with a browser running js. I'll see if I can repo, might be this weekend. Have you been able to test on macOS?

Also, re the servers you've used, do you know if they are HTTP/2 or HTTP/1.1?

Somewhat more complex, but could you make a WebSocket connection and then push the info from the server? Not sure what your app code is doing, as opposed to your example code...

Jul 26 '24 17:07 MSP-Greg

It's similar in the sense that there is no response in the network tab it's just blank and the same indefinite warning in the timing tab. Though I agree it's not the same bug just related/similar. Sometimes it happens on the 1st request, other times it takes hundreds. I saw different results based on what server I used (some internal, some public sites like Google)

In the case where it hangs, in the code the initial fetch succeeds and the headers have arrived (with a 200 status code) but it indefinitely hangs on the res.text() call

I have not got access to MacOS so no I haven't tested that.

From what I know the servers are HTTP/1.1

While I can certainly try the WebSocket approach for testing/troubleshooting - our application is very large working with a backend developed by other teams etc so it isn't a simple workaround that is really available

Jul 26 '24 18:07 johnscollins98

I'll note that my example code only uses a loop to help reproduce the issue more reliably.

In our actual application we make lots of requests to our backend and there is a just a random chance that one of them might fail.

But I didn't see any pattern as to when that would occur.

Jul 26 '24 18:07 johnscollins98

Thanks, that info helps.

Understand the issue with your backend app and WebSocket.

How many requests are normally processed in the loop? You've got an external server, is it running https? What happens to the response bodies? Are they passed back into SU's Ruby API?

Another 'I hate to ask, but' question.

Given answers to above, might it be better to make the requests in Ruby? Ruby and node.js are probably pretty similar, I've written some node.js code, but not a lot. Browser js doesn't give one the fine grained control like node.js or Ruby would.

For instance, in Ruby, you could make one connection, then run several requests over it, then repeat. Also, options like SSL session caching, etc. And CORS isn't an issue.

JFYI, I've written a lot of http/socket code in Ruby, running locally on Ubuntu and Windows, but the code is often run in GitHub Actions, and includes macOS...

Jul 26 '24 18:07 MSP-Greg

The external server is indeed https - the number of requests is extremely random, for some of my servers (a Next.js app for example) it would hang for every single request, another time I tried it took about 2,000. But the majority of the time it'll happen within 200 requests I'd say.

The response bodies are typically processed in the Ruby code and used to populate the Sketchup model (among many other things)

Doing the requests via Ruby would probably be viable but would mean a major refactor. Also we have experienced issues with the OpenSSL distribution in Ruby Net::Http so have moved away from it, any requests outside the browser we now do in C++

That said in this case the clear workaround for us in the short term is to just use SU2023 temporarily until the issue is addressed, which is what we have advised for our users. I have raised this issue as I can imagine it will be impacting other's making use of HtmlDialog for any API requests, albeit at a low probability.

Jul 26 '24 18:07 johnscollins98

Quick update, I have managed to source a MacOS device and have been able to reproduce the issue there as well:

MacBook Air M3 Mac OS Sonoma 14.5 (23F79)

Sketchup Version 24.0.554

Jul 26 '24 18:07 johnscollins98

we have experienced issues with the OpenSSL distribution in Ruby Net::Http

Interesting. Net::Http is somewhat limited as to SSL control, but I often work with Ruby master/head using OpenSSL 3.3.x since its release. If you or anyone can respond to the issues you've had, I'd be interested.

The current version of SketchUp 2024 is using OpenSSL 1.1.1w, which is EOL. Not sure what their plans are re upgrading.

To be clear, I work with 'stand-alone' Ruby much more than I work with Ruby in SketchUp...

Jul 26 '24 18:07 MSP-Greg

I verified the issue using a stand-alone Puma server (Ruby) running in WSL2/Ubuntu and SketchUp 2024. The loop froze as you found.

Using the same server (didn't restart it) and SU 2023, the first dialog I ran for 30k requests, closed it, and ran another for 100k requests.

Hence, this does appear to be a bug in SU 2024 or the CEF version it's using.

EDIT:

I did some debugging on the server side (dumped TCP socket info and the actual request text), and fetch appears to be reusing connections. Or, given how it's behaving, there isn't a need to switch to Ruby for better socket control.

Jul 27 '24 00:07 MSP-Greg

Added a topic on the Sketchup forum: https://forums.sketchup.com/t/ui-htmldialog-fetch-request-randomly-hangs/285125

Aug 13 '24 13:08 johnscollins98

Logged as: SKEXT-4288

Sep 02 '24 06:09 sketchup[bot]

UI::HtmlDialog fetch request randomly hangs

API Issues Only

Bug Reports