pjfanning opened a new pull request, #1928:
URL: https://github.com/apache/pekko-connectors/pull/1928
`ServiceAccountCredentials` and `UserAccessCredentials` both read their JSON
file like this:
```scala
val src = Source.fromFile(c.getString("path"))
val credentials =
JsonParser(src.mkString).convertTo[ServiceAccountCredentialsFile]
src.close()
```
`close()` is not in a `finally`, so a parse failure skips it and the file
descriptor leaks.
That is not a rare path — it is the expected one. The `application-default`
provider tries `parseServiceAccount` first inside a `NonFatal` catch, and on
any machine set up with `gcloud auth application-default login` the well-known
file is an *authorized user* file. So
`convertTo[ServiceAccountCredentialsFile]` throws, the descriptor leaks, and
the cascade falls through to the user access parser, which reads the same file
successfully.
One leaked descriptor per `Credentials` construction on the standard
developer path. `GoogleExt` caches settings per config path per `ActorSystem`,
so it is bounded in normal use, but `GoogleSettings(config)` is public and
un-cached, so building credentials per tenant or per request scope leaks one
each time.
Both sites now close in a `finally`.
### Testing
Four cases in `CredentialsSpec`: each parser reading its own file format,
and each parser being handed the *other* format, which is the case that used to
leak. The failure cases assert the exception still propagates, so the `finally`
is not swallowing it.
There is no portable way to assert descriptor closure from a JVM test, so
these are behavioural guards around the change rather than a direct assertion
that the handle was released. `google-common/test` passes (28) and
`checkCodeStyle` is clean.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
