Commit graph

9 commits

Author SHA1 Message Date
Scott Nonnenberg
f013eed9d1
Merge branch 'master' into development
Bringing beta up to date with production v1.0.40
2017-12-04 16:08:19 -08:00
Scott Nonnenberg
44da6924f9
A variety of logging improvements to track down bugs (#1832)
* Log when we get a blocked numbers sync message

* Save three old signed keys in addition to the current active

* Remove the mystery from all the error-related log messages

* Log successful load of signed key - to help debug prekey errors

* removeSignedPreKey: Don't hang or crash in error cases

* Log on top-level unhandled promise rejection

* Remove trailing comma in param list, Electron 1.6 does not like

* Harden top-level error handler for strange object shapes
2017-11-30 11:56:29 -08:00
Scott Nonnenberg
c94d4efd18
Beta versions support: SxS support, in-app env/instance display (#1606)
* Script for beta config; unique data dir, in-app env/type display

To release a beta build, increment the version and add -beta-N to the
end, then go through all the standard release activities.

The prepare-build npm script then updates key bits of the package.json
to ensure that the beta build can be installed alongside a production
build. This includes a new name ('Signal Beta') and a different location
for application data.

Note: Beta builds can be installed alongside production builds.

As part of this, a couple new bits of data are shown across the app:

- Environment (development or test, not shown if production)
- App Instance (disabled in production; used for multiple accounts)

These are shown in:

- The window title - both environment and app instance. You can tell
  beta builds because the app name, preceding these data bits, is
  different.
- The about window - both environment and app instance. You can tell
  beta builds from the version number.
- The header added to the debug log - just environment. The version
  number will tell us if it's a beta build, and app instance isn't
  helpful.

* Turn on single-window mode in non-production modes

Because it's really frightening when you see 'unable to read from db'
errors in the console.

* aply.sh: More instructions for initial setup and testing

* Gruntfile: Get consistent with use of package.json datas

* Linux: manually update desktop keys, since macros not available
2017-10-30 13:57:13 -07:00
Scott Nonnenberg
ffbcb4ecb5 Load debug log dialog immediately, then populate log data (#1540)
An immediate response to the user request to see the log, and then we
show the real data as soon as we've loaded it from disk.

Changes:
  - the IPC exchange to get the log data is now async
  - the API to fetch the log on the client side now returns a Promise
  - in the main process, the only disk access done synchronoously is
    reading the contents of the log directory. The JSON parsing of the
    resultant log data is now split up into three chunks.
  - We only send three keys from each log item to the renderer process:
    msg, time, level. Previously we sent the entire log entry with extra
    keys: hostname, pid, name.

FREEBIE
2017-10-04 14:40:35 -07:00
Scott Nonnenberg
fb674529f4 Override console.log in main process, handle non-strings (#1536)
This should allow us to get an insight into auto-update behavior and
other low-level behaviors happening in the Electron process which would
be useful for debugging.

FREEBIE
2017-10-04 14:03:59 -07:00
Scott Nonnenberg
f070bc4299 window.onerror: move to proper window.log.error call (#1528)
FREEBIE
2017-10-02 14:13:27 -07:00
Scott Nonnenberg
314b29e426
Redact group ids in logging
FREEBIE
2017-09-25 16:41:57 -07:00
Scott Nonnenberg
ba2df1f95b
jshint: Turn on ES6 mode, fix a few issues in new logging file
FREEBIE
2017-09-25 15:32:31 -07:00
Scott Nonnenberg
6b11f67dc6
Move logging to disk via bunyan
- Logging is available in main process as well as renderer process, and
  entries all go to one set of rotating files. Log entries in the
  renderer process go to DevTools as well as the console. Entries from
  the main process only show up in the console.
- We save three days of logs, one day per file in %userData%/logs
- The 'debug' object store is deleted in a new database migration
- Timestamps and level included in the new log we generate for publish
  as well as the devtools
- The bunyan API is exposed via windows.log (providing the ability to
  log at different levels, and save objects instead of just text), so we
  can move our code to it over time.

FREEBIE
2017-09-25 15:00:34 -07:00