http-core/src/main/scala/org/apache/pekko/http/impl/model/parser/StringBuilding.scala

has this source header

/*
 * Copyright (C) 2009-2017 Mathias Doenitz, Alexander Myltsev
 *
 * Licensed under the Apache License, Version 2.0 (the "License");
 * you may not use this file except in compliance with the License.
 * You may obtain a copy of the License at
 *
 * http://www.apache.org/licenses/LICENSE-2.0
 *
 * Unless required by applicable law or agreed to in writing, software
 * distributed under the License is distributed on an "AS IS" BASIS,
 * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
 * See the License for the specific language governing permissions and
 * limitations under the License.
 */

• LICENSE is possibly missing 3rd party code licenses due to the number of files with missing headers? Also these 3rd party files files
  • ./http-core/src/main/scala/org/apache/pekko/http/impl/engine/ws/Utf8Decoder.scala - nothing to do
  • ./http-core/src/main/scala/org/apache/pekko/http/impl/model/parser/StringBuilding.scala #249
  • ./http-core/src/main/scala/org/apache/pekko/http/impl/engine/http2/util/AsciiTreeLayout.scala #248
  • SSE #250
    • ./http-tests/src/test/java/org/apache/pekko/http/javadsl/marshalling/sse/EventStreamMarshallingTest.java
    • ./http-tests/src/test/java/org/apache/pekko/http/javadsl/unmarshalling/sse/EventStreamUnmarshallingTest.java
    • ./http-core/src/test/java/org/apache/pekko/http/javadsl/model/sse/ServerSentEventTest.java
    • ./http-core/src/main/java/org/apache/pekko/http/javadsl/model/sse/ServerSentEvent.java
    • ./http-core/src/main/java/org/apache/pekko/http/javadsl/model/headers/LastEventId.java
  • ./http-core/src/main/scala-2.13-/org/apache/pekko/http/ccompat/CompatImpl.scala - nothing to do
• These files are missing headers and are of an unknown license
  • ./docs/src/main/paradox/assets/js/scrollToFragment.js #242
  • ./http-scalafix/scalafix-tests/src/test/scala/org/apache/pekko/http/fix/RuleSuite.scala #243
• These scripts without license headers can be removed #241
  • ./scripts/authors.pl
  • ./scripts/authors.scala
  • ./scripts/commits-for-release-notes.sh
  • ./scripts/convert_tabs_to_spaces.sh
  • ./scripts/dos_to_unix.sh
  • ./scripts/find-javadoc-error.pl
  • ./scripts/release_stats.sh
  • ./scripts/remove_trailing_whitespace.sh
  • ./scripts/build/github-tagging.sh
• These files seem to have incorrect headers #240
  • ./http/src/main/boilerplate/org/apache/pekko/http/javadsl/server/JavaPathMatchers.scala.template
  • ./http/src/main/boilerplate/org/apache/pekko/http/scaladsl/server/directives/FormFieldDirectivesInstances.scala.template
  • ./http/src/main/boilerplate/org/apache/pekko/http/scaladsl/server/directives/ParameterDirectivesInstances.scala.template
  • ./http/src/main/boilerplate/org/apache/pekko/http/scaladsl/server/util/ApplyConverterInstances.scala.template
  • ./http/src/main/boilerplate/org/apache/pekko/http/scaladsl/server/util/ConstructFromTupleInstances.scala.template
  • ./http/src/main/boilerplate/org/apache/pekko/http/scaladsl/server/util/TupleAppendOneInstances.scala.template
  • ./http/src/main/boilerplate/org/apache/pekko/http/scaladsl/server/util/TupleFoldInstances.scala.template
• Remove autobahn scripts (not relevant any more, used for some extra validation on old Jenkins) #238
  • ./http-core/src/test/scripts/autobahn-jenkins/
• This file (mentioned in license) also has an incorrect header #246
  • /http-core/src/main/scala/org/apache/pekko/http/scaladsl/model/DateTime.scala
• Add a note explaning what this file is #239
  • ./http-tests/src/test/extra-libs.zip

https://github.com/apache/incubator-pekko-http/blob/5e82a0bc168644d5219b77877cbd337233aa3915/http-core/src/main/scala/org/apache/pekko/http/scaladsl/model/DateTime.scala#L191

• will probably need to track down the original Tim Kientzl code/ideas to see if we need to update our license and headers
• part of #35

Due to #14 we are now using an upstream parboiled2 rather than having our own in source version. As a result of this change we lost some minor performance improvements that was done internally which haven't been upstreamed to parboiled2 yet (see #1 (comment))

This is a meta issue to track these upstream changes

• sirthias/parboiled2#416 from d3b1322
• sirthias/parboiled2#417 from 1a50f8a
• sirthias/parboiled2#418 from 58d8f48
• sirthias/parboiled2#419 from 14f5ae3

The copy is shaded but also modified so that using the upstream version is not possible. We could probably extract the java source into its own submodule if that simplifies the license situation.

Can't remember precisely where but there are images in the current pekko Paradox docs which refer to Akka. Some examples I can remember are a visalized flamegraph and also a screenshot of a http webserver that still has Akka in it.

We should regenerate the screenshots so that they have Pekko naming instead and update the docs to reflect this.

In some .md files, we have links like:

introduction.md

See @scala[@ref[JSON Support](common/json-support.md))]@java[@ref[JSON Support](common/json-support.md#jackson-support))] for more information about integration

This is being rendered as 2 links with the same name beside each other, when I think the intent is that one shows depending on whether you've chosen Java or Scala.

See https://nightlies.apache.org/pekko/docs/pekko-http/main-snapshot/docs//introduction.html

This is just one example. I checked a few more and they have similar issues.

equivalent of apache/pekko#50

As is typical in the other Pekko codebases, we should use https://github.com/sbt/sbt-java-formatter to keep the Java sources formatted within this code. This should be done after #130 and #142 is merged so that we don't create more unnecessary conflicts.

• scala-3 branch is basically a fork of main branch but with support for Scala3.
• it has been updated with most of the recent commits to main (cherry-picked or an equivalent commit if the cherry pick did not work)
• one major commit that needs to be duplicated in scala-3 branch is 56158e4 -- this one did not cherry pick well, huge conflicts
  • I don't know of any other missing Pekko era commits that are not brought across
• there might be other commits that were missed from Akka times (ie from before Pekko work started)

https://github.com/apache/incubator-pekko-http/blob/5e82a0bc168644d5219b77877cbd337233aa3915/http-core/src/main/scala/org/apache/pekko/http/impl/engine/ws/Utf8Decoder.scala#L23-L48

• argument we should move the license bit to the file header as opposed to a Javadoc in middle of file
• need to mention in Pekko LICENSE (and pekko-http-core license)
• part of #35

The previous instance has not been run for years (was tied to legacy Jenkins setup) and scripts to run them were removed in #238.

Some things could not properly fixed to keep compatibility with Akka 2.5. Since we don't care anymore about 2.5, we can clean things up.

• stream cancellation handling (getting causes in onDownstreamFinish)

https://github.com/apache/incubator-pekko-http/actions/runs/4242607074/jobs/7374328757#step:7:2404

- should a boundary with spaces *** FAILED *** (1 second, 83 milliseconds)
[info]     java.util.concurrent.TimeoutException: Futures timed out after [1 second]
[info]     at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:259)
[info]     at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:263)
[info]     at scala.concurrent.Await$.$anonfun$result$1(package.scala:223)
[info]     at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:57)
[info]     at scala.concurrent.Await$.result(package.scala:146)
[info]     at org.apache.pekko.http.scaladsl.unmarshalling.MultipartUnmarshallersSpec.$anonfun$haveParts$1(MultipartUnmarshallersSpec.scala:440)
[info]     at org.scalatest.matchers.Matcher$$anon$1.apply(Matcher.scala:491)
[info]     at org.scalatest.matchers.should.Matchers$ShouldMethodHelperClass.shouldMatcher(Matchers.scala:6770)
[info]     at org.scalatest.matchers.should.Matchers$AnyShouldWrapper.should(Matchers.scala:6822)
[info]     at org.apache.pekko.http.scaladsl.unmarshalling.MultipartUnmarshallersSpec.$anonfun$$init$$18(MultipartUnmarshallersSpec.scala:220)

• ensure code is updated to use right prop names
• update the docs

• sbt test works fine on my laptop
• the tests in this repo are simpler than the ones in https://github.com/apache/incubator-pekko
• there could be some flaky tests that might cause issues when other people review this module (during a release, for instance)

Due to pekko-http using a custom paradox directive we should double check that the documentation looks the same before release, see #8 (comment) for more info.

• deprecated code ('since' property)
• comments

may refer to Akka HTTP 10.2.0 (as an example) - we probably need to change the code to say since = "Akka HTTP 10.2.0" to highlight that the version is not a Pekko HTTP version number.

• such code will probably need to be mentioned in our LICENSE and/or NOTICE files
• in incubator-pekko, we have examples where we have protobuf-java code used in pekko jars (as an example)
• there certainly seems to be code from the shapeless lib and this may need changes to our docs (pekko-parsing lib) -- Apache licensed: https://github.com/milessabin/shapeless
• also parboiled code (pekko-parsing lib) -- Apache licensed: https://github.com/sirthias/parboiled2

introduction.md mentions

sbt new akka/pekko-http-quickstart-scala.g8

It still contains some references to Akka pages etc that need to be cleaned up for the documentation:

pekko-http build uses .link to get the version number to use scaladoc/javadoc links
https://github.com/apache/incubator-pekko-http/blob/main/build.sbt#L429

.link provides the x.y version as opposed to x.y.z version

At the moment, for Pekko, we only publish 1.0.0 but these links point to 1.0.

Example: see the Flow[HttpRequest, HttpResponse, _] link in https://pekko.apache.org/docs/pekko-http/current/introduction.html#low-level-http-server-apis

• we could change the pekko-http build to use the x.y.z version in these links
• we could update .htaccess to redirect 1.0 to 1.0.0 (but this has a big maintenance overhead, we'd have to change the .htaccess after every release.

https://github.com/orgs/apache/projects/220/views/1?pane=issue&itemId=19613701 is ongoing

• https://incubator.apache.org/clutch/pekko.html contains a list of repos we own and the docs need updating there too

See #170

It is usually better to try to manage the lifecycle of the temp files in code so that they are deleted explicitly in code when they are no longer needed.

It looks like when the PR code above is used, that the code does remove the file explicitly - see https://github.com/apache/incubator-pekko-http/blob/20c3fea9d950d14157438918b8ba8e7747505f71/http/src/main/scala/org/apache/pekko/http/scaladsl/server/directives/FileUploadDirectives.scala#L192

Maybe, we could just remove the shutdown hook.

fyi @mdedetrich

• the existing ones are very Lightbend specific
• we are looking at creating a process in incubator-pekko - this process should closely follow that
• the new release docs might be better put in cwiki.apache.org

See comment at #39 (comment)

We should rename the package from akka to org.apache.pekko. This has somewhat higher priority specifically for this pekko module because we already have non trivial PR's open against it and to respect other peoples time we should finalize the directory structure of the project so that we aren't asking authors of PR's to do major rebase's to resolve merge conflicts against main branch.

Due to pekko-http's usage of private[akka], its not possible to change the packages without some hacky workarounds because in changing the package to org.apache.pekko you can no longer access the private[akka] internal API's. The more principled and easier way to get around this is to change the dependency to use a pekko nightly/snapshot however this is currently blocked by apache/pekko#107

A fair few tests in Pekko make http requests against Lightbend/Akka related sites (i.e. https://akka.io/), we should change these tests to make requests against our own site (i.e. https://pekko.apache.org/), likely needs to be done after we actually setup a site.

• relates to #35
• Unlike #1, there is no decision to remove the shapeless code yet.
• it could be that if #1 is merged, that we no longer need the shapeless code (I haven't checked if the parboiled2 code is the only code using the shapeless code)
• shapeless3 exists for Scala 3 but does include HList - I guess the logic is that Scala 3 tuples can do the task
• so if we do use HLIst or the other shapeless code in pekko-http (after #1 is merged or deferred) then we might want to keep the shapeless code
• if we keep it, we will need to consider updating our LICENSE and NOTICE.
  • https://github.com/milessabin/shapeless has no NOTICE
  • it is Apache licensed so we may need to document it in our license (this needs to be verified)
• relates to #62

See discussion in akka-http, there a links to RFC's etc.: akka/akka-http#659

see https://github.com/apache/incubator-pekko-http/actions/runs/5090942292/jobs/9151097224

fyi @mdedetrich

may have another cause but the recent merge is likely candidate

I spotted that some of the build params had 'akka' prefixes earlier (including one related to scaladoc diagrams) and was trying to fix that - may be related to this (#155)

The approach in #96 did not quite work.

Probably we are not getting the full-featured sbt launcher but whatever the GHA base image includes.

Akka HTTP right now contains a copy of parboiled2 in its sources (with some slight additions). This decision was originally made on the grounds that Akka should not have many dependencies on Scala libraries, so it can be released quickly after a new (incompatible) Scala version has been released.

By now, parboiled2 does not depend on shapeless any more and the ecosystem has more stabilized (and after all, maintaining the fork has not helped at all with migration to new Scala versions...). So, I'd suggest we move to upstream parboiled2.

Relates to #35

• by having a jar dependency, our licensing requirements are simplified
• by keeping a pekko copy of the source files, we need to account in more detail for this in our LICENSE and NOTICE
• one particularly problematic file is https://github.com/apache/incubator-pekko-http/blob/2e8b2fade52cf0a85d0150a407226851cf00c683/akka-parsing/src/main/java/akka/parboiled2/util/Base64.java
  • has multiple authors at various stages and BSD and Apache licensing
  • even maybe possible to use Java's Base64 class at this stage
• we even have a PR for this - #14

Currently sbt-header doesn't apply on .scala.template files, see #240

The current nightly builds publish docs but the links to the javadoc/scaladoc from the reference docs uses the full snapshot version. We do not publish to https://nightlies.apache.org/pekko/docs/pekko-http/main-snapshot/ with the full snapshot version.

Example: See HttpRequest link in https://pekko.apache.org/docs/pekko-http/current/introduction.html#low-level-http-server-apis

Today that links to https://pekko.apache.org/japi/pekko-http/0.0.0+4453-9a48d9fc-SNAPSHOT/org/apache/pekko/http/scaladsl/model/HttpRequest.html

For snapshot builds, can we change the link just to have snapshot instead of the full snapshot version?

So the link above would be https://pekko.apache.org/japi/pekko-http/snapshot/org/apache/pekko/http/scaladsl/model/HttpRequest.html - which works

The parboiled 2.5.0 update broke binary compatibility in the CharPredicate.apply() method. And un-shading this dependency in pekko has now exposed that to consumers. I'm wondering if there is any possibility of pushing a fix to parboiled (new version 2.5.1?) that brings back binary compatibility with 2.4.1?

Because we will likely remove that optimization in #14 by going back to upstream parboiled2.

Discussed in #138

Original akka-http issue: akka/akka-http#4156
Summary:

10.2.10 seems to have changed the semantics of the host connection pool max-open-requests configuration. Consider that N requests to a single host are accepted by Http().singleRequest() before a BufferOverflowException occurs. Prior to the mentioned change, N = max-open-connections. Now after this change, it appears that N = max-open-requests + max-connections.

• we have 2 copies of HashCodeCollider in 2 modules (both test code)

• https://github.com/apache/incubator-pekko-http/blob/5e82a0bc168644d5219b77877cbd337233aa3915/http-core/src/test/scala/org/apache/pekko/http/HashCodeCollider.scala#L20

• https://github.com/apache/incubator-pekko-http/blob/5e82a0bc168644d5219b77877cbd337233aa3915/http-tests/src/test/scala/org/apache/pekko/http/HashCodeCollider.scala#L20

• Might be useful to try to find a way to have just one copy of this code.

• need to update our common LICENSE file

• the http-core and http-test LICENSE files need updating

• add license headers to both copies of this file

part of #35

Both the Java and Scala CorsServerExample samples use HttpApp which is deprecated, the sample should be updated to not use HttpApp anymore.

@lomigmegard Pinging you incase you want to work on this, note that its not top priority.

• do we continue with the existing theIterators templates?
• if so, should we change how we document the templates in the pekko-http docs (eg moving them to the Examples and Extensions page)
• do we create Pekko specific ones? This might have implications in terms of having the add license headers, come up with release processes, etc.

follow up to #150 and apache/pekko#270

• in short term, we are likely to switch to plain sbt-paradox plugin
• until we have our own pekko plugin
• useful to get rid of Lightbend/Akka branding
• also seems that Lightbend copy of the plugin stops us adding links to other web sites (like the Akka site)

Relates to #33

Unless we need to specifically talk about Akka - in most cases, we will be adjusting the text to talk about Pekko.

Any mentions of Akka 2.6 or Akka HTTP 10.2 (for instance) - need to be changed to refer to Pekko 1.0.0 or Pekko HTTP 1.0.0 respectively.

see https://github.com/apache/incubator-pekko-http/actions/runs/5427033437/jobs/9878610786

has issues like:

`[https://docs.oracle.com/en/java/javase/11/docs/api/java/util/Map.html`](https://docs.oracle.com/en/java/javase/11/docs/api/java/util/Map.html) status 404 Not Found
 - ../../../../../target/scala-2.13/unidoc/org/apache/pekko/http/javadsl/model/headers/HttpCredentials.html
 - ../../../../../target/scala-2.13/unidoc/org/apache/pekko/http/javadsl/server/AllDirectives.html
 - ... 3 more

should be https://docs.oracle.com/en/java/javase/11/docs/api/java.base/java/util/Map.html

The sbt settings closely match those in incubator-pekko but the scaladoc is generating ok in incubator-pekko

In the #34 PR, specific markdown text was removed from the handling-blocking-operations-in-pekko-http-routes.md file, i.e. https://github.com/apache/incubator-pekko-http/pull/34/files/38af0a2735a3cdf5339490d5f1d3acd910cc65a5#diff-6ff1d12760e28d4b30391860625c906ad82391240593ad8dabd7e93e2c7b571aL69 . Incase you have issues viewing the diff the precise text that was removed is

@java[The same happens to the global @apidoc[ForkJoinPool] when using Java Futures.]

after the however they go to sleep state immediately, thus wasting the resources. sentance.

The reason why the text was removed was that due to the change in that PR in renaming the package from akka to org.apache.pekko, it caused paradox to make a compilation error on that text. Even when trying to use a FQCN i.e.

@java[The same happens to the global @apidoc[java.util.concurrent.ForkJoinPool] when using Java Futures.]

It still didn't compile. I suspect that the root cause is before the package name change, some weird shadowing was going on with the akka package, and because of this the @apidoc[ForkJoinPool] was actually pointing to akka.dispatch.forkjoin.ForkJoinPool and not java.util.concurrent.ForkJoinPool (which I think is incorrect judging from the context of whats being described).

See https://github.com/apache/incubator-pekko-http/blob/1371cf06e2bd6a79be6afa977e3e45ced0f398bb/http-core/src/main/scala-2.13-/org/apache/pekko/http/ccompat/CompatImpl.scala#L22

Very simple reproducer with explanation: https://github.com/mkurz/akka-http-percent-encoding-bug (that reproducer is still based on akka-http but should work 1:1 when applied to pekko-http)

Copy and pasted README (in case I ever delete that repo):

pekko-http's (experimental?) http2 support does not correctly handle URL parsing errors.
Specially when passing an invalid percent-encoded character in the path and/or query string (here %_D):

As reproducer the example from the akka docs can be used, but with HTTP/2 enabled:

• https://doc.akka.io/docs/akka-http/current/introduction.html#low-level-http-server-apis
• https://doc.akka.io/docs/akka-http/current/server-side/http2.html#enable-http-2-support

# Start the server
sbt run

# HTTP/1 works:
$ curl --http1.1 -v http://localhost:8080/?param=%_D
*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET /?param=%_D HTTP/1.1
> Host: localhost:8080
> User-Agent: curl/7.87.0
> Accept: */*
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 400 Bad Request
< Server: akka-http/10.2.10
< Date: Wed, 15 Feb 2023 16:29:18 GMT
< Connection: close
< Content-Type: text/plain; charset=UTF-8
< Content-Length: 78
< 
* Closing connection 0
Illegal request-target: Invalid input '_', expected HEXDIG (line 1, column 10)

# HTTP/2 gives error:
$ curl --http2-prior-knowledge -v http://localhost:8080/?param=%_D
*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
* Using HTTP2, server supports multiplexing
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* h2h3 [:method: GET]
* h2h3 [:path: /?param=%_D]
* h2h3 [:scheme: http]
* h2h3 [:authority: localhost:8080]
* h2h3 [user-agent: curl/7.87.0]
* h2h3 [accept: */*]
* Using Stream ID: 1 (easy handle 0xaaabd90f0dc0)
> GET /?param=%_D HTTP/2
> Host: localhost:8080
> user-agent: curl/7.87.0
> accept: */*
> 
* Connection state changed (MAX_CONCURRENT_STREAMS == 256)!
* Closing connection 0
curl: (16) Error in the HTTP2 framing layer

At some point, no matter if using HTTP/1 or HTTP/2, the parser ends up here

• https://github.com/apache/incubator-pekko-http/blob/6624fa98f43849f791bccd14c1ec3d80d091a994/http-core/src/main/scala/org/apache/pekko/http/impl/model/parser/UriParser.scala#L253-L256

As you can see it will (also) be looked for pct-encoded characters, which expect a % sign, followed by two HEXDIG signs:

• https://github.com/apache/incubator-pekko-http/blob/6624fa98f43849f791bccd14c1ec3d80d091a994/http-core/src/main/scala/org/apache/pekko/http/impl/model/parser/UriParser.scala#L300-L305

Now if that fails...

• ...when using HTTP/1...

...then the method parseHttpRequestTarget fails with (=throws) an IllegalUriException, which will later be handled so a 400 Bad Request with following body will be send:

Illegal request-target: Invalid input '_', expected HEXDIG (line 1, column 10)

(There are various places in the http-core module where IllegalUriExceptions and ParsingExceptions are caught and handled)

• ...when using HTTP/2...

PathAndQuery.parse in following line throws an ParsingException which is never handled (this is in the org.apache.pekko.http.impl.engine.http2 package, so not used by HTTP/1):

• https://github.com/apache/incubator-pekko-http/blob/6624fa98f43849f791bccd14c1ec3d80d091a994/http-core/src/main/scala/org/apache/pekko/http/impl/engine/http2/hpack/HeaderDecompression.scala#L71

A couple of lines later only an IOException gets caught:

• https://github.com/apache/incubator-pekko-http/blob/6624fa98f43849f791bccd14c1ec3d80d091a994/http-core/src/main/scala/org/apache/pekko/http/impl/engine/http2/hpack/HeaderDecompression.scala#L86-L96

If you see where the containing method parseAndEmit gets called, the ParsingException never gets handled.

Expected Result

When using HTTP/2 I would expect to also receive a 400 Bad Request with the body:

Illegal request-target: Invalid input '_', expected HEXDIG (line 1, column 10)

This scripted test, migrated to pekko in playframework/playframework#11847

• Works fine with Scala 2.13 ✔️
• Fails with Scala 3 ❌

Seems like this has to do with how unapply methods changed in Scala 3 (?)

• https://docs.scala-lang.org/scala3/guides/migration/incompat-other-changes.html#explicit-call-to-unapply
• https://docs.scala-lang.org/scala3/reference/changed-features/pattern-matching.html

Snapshot used:

• pekko-http: 0.0.0+4411-6fe04045-SNAPSHOT
• pekko: 0.0.0+26669-ec5b6764-SNAPSHOT

[error] Uncaught error from thread [application-pekko.actor.default-dispatcher-4]: 'org.apache.pekko.stream.TLSProtocol$SessionBytes org.apache.pekko.stream.TLSProtocol$SessionBytes$.unapply(org.apache.pekko.stream.TLSProtocol$SessionBytes)', shutting down JVM since 'pekko.jvm-exit-on-fatal-error' is enabled for ActorSystem[application]
[error] java.lang.NoSuchMethodError: 'org.apache.pekko.stream.TLSProtocol$SessionBytes org.apache.pekko.stream.TLSProtocol$SessionBytes$.unapply(org.apache.pekko.stream.TLSProtocol$SessionBytes)'
[error]         at org.apache.pekko.http.impl.engine.http2.ProtocolSwitch$$anon$1$$anon$2.onPush(ProtocolSwitch.scala:65)
[error]         at org.apache.pekko.stream.impl.fusing.GraphInterpreter.processPush(GraphInterpreter.scala:555)
[error]         at org.apache.pekko.stream.impl.fusing.GraphInterpreter.execute(GraphInterpreter.scala:433)
[error]         at org.apache.pekko.stream.impl.fusing.GraphInterpreterShell.runBatch(ActorGraphInterpreter.scala:662)
[error]         at org.apache.pekko.stream.impl.fusing.GraphInterpreterShell$AsyncInput.execute(ActorGraphInterpreter.scala:532)
[error]         at org.apache.pekko.stream.impl.fusing.GraphInterpreterShell.processEvent(ActorGraphInterpreter.scala:637)
[error]         at org.apache.pekko.stream.impl.fusing.ActorGraphInterpreter.org$apache$pekko$stream$impl$fusing$ActorGraphInterpreter$$processEvent(ActorGraphInterpreter.scala:813)
[error]         at org.apache.pekko.stream.impl.fusing.ActorGraphInterpreter$$anonfun$receive$1.applyOrElse(ActorGraphInterpreter.scala:831)
[error]         at org.apache.pekko.actor.Actor.aroundReceive(Actor.scala:547)
[error]         at org.apache.pekko.actor.Actor.aroundReceive$(Actor.scala:545)
[error]         at org.apache.pekko.stream.impl.fusing.ActorGraphInterpreter.aroundReceive(ActorGraphInterpreter.scala:729)
[error]         at org.apache.pekko.actor.ActorCell.receiveMessage(ActorCell.scala:590)
[error]         at org.apache.pekko.actor.ActorCell.invoke(ActorCell.scala:557)
[error]         at org.apache.pekko.dispatch.Mailbox.processMailbox(Mailbox.scala:280)
[error]         at org.apache.pekko.dispatch.Mailbox.run(Mailbox.scala:241)
[error]         at org.apache.pekko.dispatch.Mailbox.exec(Mailbox.scala:253)
[error]         at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:290)
[error]         at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1020)
[error]         at java.base/java.util.concurrent.ForkJoinPool.scan(ForkJoinPool.java:1656)
[error]         at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1594)
[error]         at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:183)

Line triggering the exception:
https://github.com/apache/incubator-pekko-http/blob/0dc1da23cc465d8795f33daa513298afc2841ab5/http-core/src/main/scala/org/apache/pekko/http/impl/engine/http2/ProtocolSwitch.scala#L65

SessionBytes:

  final case class SessionBytes(session: SSLSession, bytes: ByteString)
      extends SslTlsInbound
      with scaladsl.ScalaSessionAPI

scaladsl.ScalaSessionAPI:
https://github.com/apache/incubator-pekko/blob/main/stream/src/main/scala/org/apache/pekko/stream/scaladsl/TLS.scala#L249-L294

In case it's needed, if you want to run the scripted tests yourself let me know, so I can give instructions. see comment below