The API endpoint listening for a dump of process logs was not returning logs properly for two reasons:
1. The `id` field was being appended to each log. This had been moved to the `handleLog` function of the `LogHandler`.
2. The slice needed to grab logs from the end, so the `limit` was made negative on the `.slice()`.
Default behavior of logging to file is no longer needed now that Embark log history can be properly served using the `ProcessLogsApi` and `LogHandler` classes.
# Conflicts:
# lib/core/logger.js
# lib/modules/blockchain_process/blockchain.js
There are three separate instances of process log APIs: embark logs, blockchain logs (when in standalone mode), and child process logs (storage, communication, blockchain, etc). Each one was repeating the implementation of creating a process log API endpoint. This commit centralises the API declaration by using the class `ProcessLogsApi`.
`ProcessLogsApi` is started for all three components mentioned above: blockchain (in standalone) in the `BlockchainListener` module, embark in the `EmbarkListener` module, and for all child processes in the `ProcessLauncher`.
These listeners have two functions:
1. Create the process logs API endpoints for `get` and `ws`, and
2. Ensure that all logs are logged through the `LogHandler`, which normalises the output of the log and ensures each log has a timestamp and id (used in the cockpit for log ordering).
Also, this commit moved the pipeline in to a module, so that the `embark` object could be passed to the `ProcessLogsApi` (to be used for registering API endpoints).
When running `embark blockchain` followed by `embark run` previously, logs generated in the standalone `embark blockchain` process were black boxed and not accessible to the main Embark process.
This is fixed by creating a client IPC connection in the `embark blockchain` process that connects to the IPC server connection running in `embark run`. The connection is made by way of polling `ipc.connect` and continues polling even after a connection is made in case `embark run` is killed and restarted without restarting `embark blockchain`.
`LogHandler` was introduced to extrapolate functionality used in `ProcessLauncher` that needed to also be used in the standalone blockchain process. It also caps the number of logs that are stored in memory per process by a constant value defined in `constants.json`.
A `blockchain_listener` was module was created (and run inside of `embark run`) that listens for logs emitted by the `embark blockchain` client IPC and runs them through the `LogHandler`. Additionally, this module registers the API endpoints needed to handle requests for blockchain process logs in the cockpit (which were 404’ing before).
# Conflicts:
# lib/modules/blockchain_process/blockchain.js
We don't presently have a way to cleanly distinguish between auth attempts with
query string vs. credentials from localStorage, particularly with respect to
one kind failing vs. the other. This can create confusing behavior when
e.g. copy/pasting an old/wrong URL+token, but then it works when refreshing the
window/tab with URL minus the token.
So, this commit simplifies the situation somewhat by triggering a logout
if there's an auth failure. That will affect all open tabs/windows of the
same browser but not other browsers, e.g. if one has embark-ui open in Chrome
and Firefox.
Anthony Laibe
Iuri Matias
Jonathan Rainville
Pascal Precht
emizzle
Michael Bradley, Jr