TLS 1.3 handshake server name indication is missing on a session resume

A customer showed me a case where a TLSv1.3 handshake is failing, but passes on TLSv1.2 on JDK 11. It also doesn't fail in TLSv1.2 on JDK 10.

Customer is primarily using: URL.openConnection()/getInputStream()

In a simple connection, I am seeing the right server_name extension for <hostname> going out. The certificates received from the server are also for <hostname>:

  "extensions" : [
    "server_name (0)": {
      type=host_name (0), value=<hostname>
    },
...deleted...
javax.net.ssl|DEBUG|01|main|2018-10-05 14:41:28.941 PDT|CertificateMessage.java:1148|Consuming server Certificate handshake message (
"Certificate": {
  "certificate_request_context": "",
  "certificate_list": [
  {
    "certificate" : {
      "issuer" : "CN=Let's Encrypt Authority X3, O=Let's Encrypt, C=US",
      "subject" : "CN=<hostname>",

with alternate names for:

          SubjectAlternativeName [
            DNSName: <hostname>
            DNSName: www.&lt;hostname>
          ]

However, in the debug log he showed me, I didn't see the server_name extension going out in the second connection, and noticed this in the debug log:

javax.net.ssl|DEBUG|81|Thread-78|2018-09-27 18:20:46.303 PDT|Utilities.java:73|the previous server name in SNI (type=host_name (0), value=<hostname>) was replaced with (type=host_name (0), value=<hostname>)

and the certificate received was for:

      "subject" : "CN=*.<hostname2>,

Are they running <hostname> on a virtual server named <hostname2>?

So something about the server name indication seems to be going haywire.

That's my best guess.

----some additional notes----

It appears to be a race condition between how connections are created, as it doesn't always happen. Sometimes the app will work fine, but othertimes it's almost immediate. Outputting "all" debug information reduced the frequency of occurrence, but would eventually happen.

There is currently not a simple reproducible test case. But the two error logs show the same error, one from the debug output, and one from the wireshark output.
 
See the later comments for additional information.