Skip to content

fix(hosting): a hosting panel that does not answer no longer gives the customer a 500 - #185

Merged
Panelica merged 4 commits into
Panelica:mainfrom
ertugrulkeyvan:fix/hosting-tabs-panel-unreachable
Oct 11, 2026
Merged

Panelica merged 4 commits into
Panelica:mainfrom
ertugrulkeyvan:fix/hosting-tabs-panel-unreachable

Conversation

@ertugrulkeyvan

Copy link
Copy Markdown
Contributor

What

When the hosting panel does not answer, the customer gets a message instead of a 500 "Server Error".

Every hosting tab on a service asks the panel first: email, DNS, files, FTP, databases, cron, Node.js, backups, containers and subdomains. When the panel was unreachable, the request's ConnectionException went up past all of them as a 500.

We saw it when we cut a test install off from its panel. All ten tabs gave "Server Error", and each kept the browser waiting for the connection attempt first.

After this:

  • Opening a tab: the customer lands on the service page with "The hosting control panel is not answering right now. Please try again in a few minutes."
  • Sending a form on a tab (adding a mailbox, a DNS record, …): they go back to the form, with what they typed and the same message. Passwords are not kept.
  • Panelica connections: a connection to a Panelica server now gives up after 5 seconds instead of the default 10. A down panel holds the page for 5 seconds; a slow but reachable one is unaffected, because only connecting is limited, not the request.

Unchanged:

  • The service page itself is not intercepted, so a redirect can never loop. It opens while the panel is down.
  • JSON requests, other areas and the API keep the framework's own handling.
  • The ownership check still comes first: another customer's tab is a 403 before the panel is asked.

How

  • bootstrap/app.php: a renderer for Illuminate\Http\Client\ConnectionException on client.services.* routes, except client.services.show and JSON requests. A GET with a service goes to the service page; anything else goes back with input. The failure is logged with the route name.
  • PanelicaModule: connectTimeout(5) on every request it makes to the panel.
  • Text: client.hosting.panel_unreachable in en, tr, de, pl and zh.

The work is split into four commits: the handler, the translations, the connect timeout and the tests.

Tests

tests/Feature/HostingPanelUnreachableTest.php, 6 tests, with Http::failedConnection():

  • Tabs: email, DNS and databases redirect to the service page with the message.
  • Forms: adding a mailbox returns to the form with the message.
  • Ownership: another customer's tab is still a 403.
  • Service page: it opens while the panel does not answer.

Four of them fail on main. All Panelica tests pass unchanged.

Full suite: 4092 passed. The one failure is the CurrencyAndBackupTest db backup test, which fails on main too in my local setup.

@Panelica
Panelica merged commit 05a1f2f into Panelica:main Oct 11, 2026
@Panelica

Copy link
Copy Markdown
Owner

Thank you, @ertugrulkeyvan, merged. A panel that is down now gives the customer a clear message instead of a "Server Error", and the five-second connect limit stops a dead panel from holding the page.

One note on the merge: #180 had just added the mail certificate texts at the end of lang/*/client.php, so client.hosting.panel_unreachable now follows them in all five languages. Nothing else changed.

Full suite green.

Panelica pushed a commit that referenced this pull request Oct 12, 2026
feat(orders): free subdomains for hosting orders

lang/*/admin.php and lang/*/client.php: the keys #180, #184 and #185 added and the ones added here are all kept, in that order in every language.
Panelica pushed a commit that referenced this pull request Oct 12, 2026
… form the panel may have carried out says so

#185 gave every call to a Panelica panel five seconds to connect. That was
meant for a customer waiting on a page. The scheduler, the queue and staff
screens wait ten again, Laravel's default, so a slow network does not fail an
account that is being set up or suspended.

A ConnectionException is also what a request that reached the panel and was
not answered in time gives. After a form (a container being deployed, a
backup), "try again in a few minutes" could do the work twice. When cURL
reports that the request was sent, the customer is told it may still be done
there and to check before trying again; a page that was only being read keeps
the old message. App\Support\ConnectionFailure reads this from cURL's transfer
figures, or from its message when there are none.

The file editor's content is no longer kept in the session after a failed
save; the editor reads the file from the panel again.

New message client.hosting.panel_no_answer_in_time in en, tr, de, pl and zh.
The three new behaviours are tested and fail on main.
@Panelica

Copy link
Copy Markdown
Owner

Thank you again for #185, @ertugrulkeyvan. We added a follow-up on main, 7c00ec7:

  • Connect timeout: the five seconds now apply while a customer waits on one of their own pages. The scheduler, the queue and staff screens wait ten again, Laravel's default, so a slow network does not fail an account that is being set up or suspended (those calls are queued and retried).
  • A form the panel may have carried out: a ConnectionException is also what a request that reached the panel and was not answered in time gives. After a form such as a container deployment or a backup, "try again in a few minutes" could do the work twice. When cURL reports that the request was sent, the customer is now told it may still be done and to check before trying again. Pages that were only being read keep your message. App\Support\ConnectionFailure reads this from cURL's transfer figures, or from its message when there are none.
  • File editor: the content of a file that could not be saved is no longer kept in the session; the editor reads the file from the panel again.

Each has a test that fails without the change, and the full suite passes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants