zweidenker / snapdump Goto Github PK

Dumps are uploaded with project and version number. We need to specify a source where the images can be acquired so the downloaded dump will fit

In order to load proper client code the server should answer the version it has been built from

Current client is rather limited with modal dialogs. Having a proper model allows to use those via GTInspector

Both baselines need to be combined and core, server and client should be groups

From the UI client, if you click the "Stack trace" button, you get this kind of exception:

"Illegal leading byte for utf-8 encoding"

In order to reproduce, one could report a samp snaphot with this piece of code:

[Error signal: 'My first SnapDump snapshot']
on: Error
do: [ :error |
Smalltalk
at: #SnapDump
ifPresent: [ :reporter |
reporter handleException: error]].

The resulting snapshot snapshot will trigger the exception when fetch from a UI client

The maximum number of snapshots that can be reported for a given exception is currently harcoded (it is set to 10).
This value should be configurable, and initialised at SnapDump server startup

It would be nice to still be able to take advantage of snapshots without having the exact same image context than the reported exception.
The UI could offer to display / download stack traces for a given snapshot.

In order to achieve that, we could add a "stack trace string" to the persisted snap file

The snap dump file format at the moment is a simple format that consists of text sections followed by a binary section containing a fuel dump. The separator between the text sections is a 255 byte which is unlikely to appear solely in an utf8 encoded string. But the constraint is too weak IMHO.
Needs to be more solid meaning it should be either an illegal utf8 sequence or we should change the format to TLV

An idea that came up is to make server calls expect a version as first part of their path

This would help in the context of having multiple SnapDump servers running at the same time but with different versions.
A handler would have to use a version number in its url that matches the version of the target server.

I see the advantage as forcing snapdump users to consider version compatibility between handler and server.
We could have explicit error message when version numbers do not match.
That could prevent server from perfoming inconsistent actions if versions are not compatible

Another solution would be to let snapdump users administrate such concern completly outside pharo.
If they use specific urls to target a a given instance of snapdump server, they should make sure the path that end up into snapdump server instance is "refined"

The dockerhub configuration is not aligned with the github builds. Come up with a release scheme that matches github and dockerhub

There is at least one dependency in #SDServer>>repositoryDescription.

this should be replaced by a static version set while setting up the image. This version can then be used by the SDServerVersionCall handler as well as by the SnapDumpAPI>>info

remove dependency to openapi

Server and Client can share the basic model about project, version, and dump parameters. Especially the client needs to rely on that