FR: retry configuration and onError callback
Nobody has claimed this yet.
- Dominant language
- R
- Stars
- 255
- Forks
- 33
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 2
Description
Background: I'd like to create a shiny app which is able to reconnect to a database once the connection is lost (without crashing the active shiny session).
Currently, when using dbPool and the database server is shutdown (I stopped the PostgreSQL service for testing) after successfully establishing a connection, {pool} will retry 2 times and throw an error after a few seconds (default validationInterval = 60):
Failed to activate and/or validate existing object.
Trying again with a new object.
Error: connection to server at "localhost" (::1), port 5432 failed: Connection refused (0x0000274D/10061)
Is the server running on that host and accepting TCP/IP connections?
connection to server at "localhost" (127.0.0.1), port 5432 failed: Connection refused (0x0000274D/10061)
Is the server running on that host and accepting TCP/IP connections?
Error: invoke_wrapped: throwing std::runtime_error
Unfortunately, (afaik) I don't have the possibility to configure this behaviour, e.g. retry 5 times wait x seconds or retry forever.
Furthermore, as this is happening in a background process I can't use tryCatch to write my own error handling for this case (also afaik) - maybe a onError callback could be added?
I would be pleased to hear your opinion on this - cheers
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by examining the dbPool retry and validation behavior described in the issue, including how background errors are surfaced when PostgreSQL becomes unavailable. Review the existing pool configuration and error-handling entry points. Done would require an agreed design and documented, tested support for configurable retries and/or an onError callback.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- postgresql, r
- Domain
- backend, databases
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100