-
-
Notifications
You must be signed in to change notification settings - Fork 69
Feat: (Health check) Check alt_ip if web domain is not accessible
#768
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
|
Deployed to https://msg-adamant-pr-768.surge.sh 🚀 |
|
The logic becomes more complex, it'd be good to write tests for different use-cases. |
|
@S-FrontendDev @bludnic |
…onnection once per cycle
|
…e (domain/IP) during a session
|
@adamant-al @adamantmm @S-FrontendDev The following case has been fixed:
In other words, the final logic is: persistently save the connection type (domain/IP) during a session (until a user refreshes the page or disables/enables the node using the checkbox) for each node after the first successful connection |
fyi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Test case failed.
url: tauri.adm.im
alt_ip: 154.26.159.245:36666
The application tries a health check (api/node/status) on the domain tauri.adm.im.
- Open Nodes screen
- Domain is accessible
- Done: Save this state, and all subsequent requests (both health checks and data requests) go to tauri.adm.im.
- Block
*tauri*in Dev Tools. - Health check request fails, but the node is NOT considered (temporarily) offline, it is shown as "online" with outdated height, then status changed from "online" to "syncing".
Expected in (5):
- Health check request fails, the node is considered (temporarily) offline, it is shown as "offline", and not used for app requests.
- After node goes back online, it's included in the list of live nodes, and may be "online" or "syncing" depending on its height (as usual).
…if health check fails
|
|
@adamantmm is test passed? |
Yes, it is. Waiting for "Verbose logging" not to spam in logs, and then we can merge. |
… others at info level
Task check list
debuglevel, everything else atinfoTask description
To test this complex algorithm clearly, in the
src/config/development.jsonleave only one list with one entry.There are 3 possible cases, let's take a look at the example of ADAMANT nodes:
{ "adm": { "nodes": { "list":[ { "url": "https://debate.adamant.im", "alt_ip": "http://95.216.161.113:36666" } ] } } }{ "adm": { "nodes": { "list":[ { "url": "https://abc.adamant.im", "alt_ip": "http://95.216.161.113:36666" } ] } } }{ "adm": { "nodes": { "list":[ { "url": "https://abc.adamant.im", "alt_ip": "http://123.123.123.123:36666" } ] } } }Remember to filter out log messages and leave only
console.infoTest cases
url: tauri.adm.im
alt_ip: 154.26.159.245:36666
The application tries a health check (
api/node/status) on the domain tauri.adm.im.a) Domain is accessible
This is not a node ban — the node may be temporarily offline.
b) Domain is not accessible
api/node/status) on IP 154.26.159.245:36666.This is not a node ban — the node may be temporarily offline.
c) Neither domain nor IP is accessible