elixir-error-tracker / error-tracker

🐛 An Elixir-based built-in error reporting and tracking solution

🐛 ErrorTracker

An Elixir based built-in error tracking solution.

Configuration

Take a look at the Getting Started guide.

Development

Initial setup and dependencies

If this is the first time that you set up this project you will to generate the configuration files and adapt their content to your local environment:

cp config/dev.example.exs config/dev.exs
cp config/test.example.exs config/test.exs

Then, you will need to download the dependencies:

mix deps.get

Assets

In order to participate in the development of this project, you may need to know how to compile the assets needed to use the Web UI.

To do so, you need to first make a clean build:

mix do assets.install, assets.build

That task will build the JS and CSS of the project.

The JS is not expected to change too much because we rely in LiveView, but if you make any change just execute that command again and you are good to go.

In the case of CSS, as it is automatically generated by Tailwind, you need to start the watcher when your intention is to modify the classes used.

To do so you can execute this task in a separate terminal:

mix assets.watch

Development server

We have a dev.exs script that starts a development server.

To run it together with an IEx console you can do:

iex -S mix dev

error-tracker's Issues

Error loading assets on a mix release

I have added the error_tracker_dashboard at /errors in router. This works fine when run locally using an iex shell.

Deploying the app to Fly IO it will fail to load the page with the error:

Request: GET /errors

[info] ** (exit) an exception was raised:

[info] ** (File.Error) could not read file "/app/_build/prod/lib/error_tracker/priv/static/app.css": no such file or directory

Some possibly useful snippets from the Dockerfile used to generate the image being ran:

RUN cd assets && npm install 

COPY package.json package.json
RUN npm install

# compile assets
RUN mix assets.deploy

# Compile the release
RUN mix compile

# Changes to config/runtime.exs don't require recompiling the code
COPY config/runtime.exs config/

COPY rel rel
RUN mix release

...

# Only copy the final release from the build stage
COPY --from=builder --chown=nobody:root /app/_build/${MIX_ENV}/rel/app_name ./

USER nobody

# If using an environment that doesn't automatically reap zombie processes, it is
# advised to add an init process such as tini via `apt-get install`
# above and adding an entrypoint. See https://github.com/krallin/tini for details
# ENTRYPOINT ["/tini", "--"]

CMD ["/app/bin/server"]

Improve error grouping

Fingerprinting the error reason breaks grouping for certain kind of errors.

For example a KeyError would provide a reason similar to:

key :whatever not found in %{...}

The map could have different values on different executions and this would result in a different reason which, in turn, would result in a different fingerprint causing occurrences to be recorded as different errors.

---

We need to move the reason into the occurrence and just store the initial reason in the error for presentation purposes.

bug: argument error after insert

I'm getting this error:

[error] ** (ArgumentError) cannot load `<<152, 139, 52, 172, 79, 76, 17, 239, 181, 22, 11, 103, 23, 163, 197, 255>>` as type :id for field `id` in schema ErrorTracker.Error
    (ecto 3.11.2) lib/ecto/repo/schema.ex:859: Ecto.Repo.Schema.load_each/4
    (ecto 3.11.2) lib/ecto/repo/schema.ex:832: Ecto.Repo.Schema.load_changes/8
    (ecto 3.11.2) lib/ecto/repo/schema.ex:382: anonymous fn/15 in Ecto.Repo.Schema.do_insert/4
    (ecto 3.11.2) lib/ecto/repo/schema.ex:273: Ecto.Repo.Schema.insert!/4
    (hsm 0.9.2) lib/hsm/repo.ex:3: Hsm.Repo.insert!/2
    (error_tracker 0.1.0) lib/error_tracker.ex:122: ErrorTracker.report/3
    (error_tracker 0.1.0) lib/error_tracker/integrations/plug.ex:102: ErrorTracker.Integrations.Plug.report_error/3
    (hsm 0.9.2) lib/hsm_web/endpoint.ex:1: HsmWeb.Endpoint.call/2
    (phoenix 1.7.14) lib/phoenix/endpoint/sync_code_reload_plug.ex:22: Phoenix.Endpoint.SyncCodeReloadPlug.do_call/4
    (bandit 1.5.5) lib/bandit/pipeline.ex:124: Bandit.Pipeline.call_plug!/2
    (bandit 1.5.5) lib/bandit/pipeline.ex:36: Bandit.Pipeline.run/4
    (bandit 1.5.5) lib/bandit/http1/handler.ex:12: Bandit.HTTP1.Handler.handle_data/3
    (bandit 1.5.5) lib/bandit/delegating_handler.ex:18: Bandit.DelegatingHandler.handle_data/3
    (bandit 1.5.5) /home/frank/git/hsm-rose-fixes/deps/thousand_island/lib/thousand_island/handler.ex:411: Bandit.DelegatingHandler.handle_continue/2
    (stdlib 6.0) gen_server.erl:2163: :gen_server.try_handle_continue/3
    (stdlib 6.0) gen_server.erl:2072: :gen_server.loop/7
    (stdlib 6.0) proc_lib.erl:329: :proc_lib.init_p_do_apply/3

Since it's dealing with the :id field, here are my Ecto settings that may be relevant:

config :hsm,
  ecto_repos: [Hsm.Repo],
  generators: [binary_id: true]

config :hsm, Hsm.Repo,
  migration_primary_key: [
    name: :id,
    type: :binary_id,
    autogenerate: false,
    read_after_writes: true,
    default: {:fragment, "uuid_generate_v1mc()"}
  ],
  migration_timestamps: [type: :utc_datetime_usec]

Handler ErrorTracker.Integrations.Phoenix has failed and has been detached

Trying to test out the project but I can't seem to get any errors logged. The error occurs at this line

error-tracker/lib/error_tracker.ex

Line 116 in 12da0c3

{:ok, stacktrace} = ErrorTracker.Stacktrace.new(stacktrace)

I put a sample erronous code 1 + "a" into a LiveView and got the following error:

[error] Handler ErrorTracker.Integrations.Phoenix has failed and has been detached. Class=:error
Reason={:badmatch,
 {:error,
  #Ecto.Changeset<
    action: :new,
    changes: %{
      lines: [
        #Ecto.Changeset<
          action: :insert,
          changes: %{function: "+", module: "erlang"},
          errors: [arity: {"is invalid", [type: :integer, validation: :cast]}],
          data: #ErrorTracker.Stacktrace.Line<>,
          valid?: false
        >,
        ...

I also tried changing a function call to use an invalid name (changing AshPhoenix.LiveView.page_from_params to AshPhoenix.LiveView.page_from_params1, and got a similar error:

[error] Handler ErrorTracker.Integrations.Phoenix has failed and has been detached. Class=:error
Reason={:badmatch,
 {:error,
  #Ecto.Changeset<
    action: :new,
    changes: %{
      lines: [
        #Ecto.Changeset<
          action: :insert,
          changes: %{
            function: "page_from_params1",
            module: "AshPhoenix.LiveView",
            application: "ash_phoenix"
          },
          errors: [arity: {"is invalid", [type: :integer, validation: :cast]}],
          data: #ErrorTracker.Stacktrace.Line<>,
          valid?: false
        >,
        ...

Are these not classes of errors that can be tracked at the moment?

Detect & format GQL queries / mutations

Would be great to detect GraphQL queries / mutations and format them along with their variables.

Do not track cookies automatically

Cookies may contain sensible information and should not be tracked by default.

Searching errors through the dashboard using SQLite results in Ecto.QueryError

Searching through the web dashboard doesn't work because SQLite (and other DBs) doesn't support Postgres' ILIKE:

ilike is not supported by SQLite3 in query:

from e0 in ErrorTracker.Error,
  where: ilike(e0.reason, ^...),
  select: count()

A possible solution would be to change the private filter function lib/error_tracker/web/live/dashboard.ex depending on the DB. ILIKE for Postgres and LIKE for other DBs (which search case-insensitive by default).

  defp do_filter({field, value}, query) do
    # conditional filter based on DB?
    where(query, [error], ilike(field(error, ^field), ^"%#{value}%"))
  end

Wrap Ecto.Repo

Calling ErrorTracker.repo().whatever(..., prefix: ErrorTracker.prefix()) every time gets annoying quickly.

Let's build an ErrorTracker.Repo module that exposes the same API as Ecto.Repo and does this for us.

How to merge css / js?

Maybe just be a newbie question, but I get zero styling on error_tracker_dashboard. I followed the setup guide but I don't know how the assets should be merged.

Cannot get migration working

Ignore! User error.

Organize dev code

If we are going to have multiple dev scripts for controller, live views and plugs we will need to extract some common logic outside of the dev scripts. For example, the repository and database set up is always the same.

It may be a good idea to extract that logic into a few modules that are only compiled during development (for script usage). The part that I would like to abstract more is the database setup and migration so we don't have to repeat that every time.

Document how static assets are included in the dashboard

Both CSS and JS are read during compilation and inlined in the ErrorTracker dashboard. This may not be obvious for users of the library and may cause trouble in certain cases such as #45

We should document this explicitly for users to know. Depending on the CSP configuration they may need to allow inline styles and scripts for the dashboard to work.

Improve development setup

Instead of running from a dev.exs script we could make a dev/ or lib/dev/ folder that would work similarly to test/support/. It would be only compiled on dev and test environments and wouldn't be included in the published package.

This would have a few benefits:

1. Would make it easier to run mix commands. Currently many modules are only available when running dev.exs directly.
2. Would allow us to reuse code between dev and tests. The repository is the same between the two but it has to be duplicated for now.
3. Would make it easier to understand and modify the different pieces of code. The single-file-script-with-multiple-modules pattern is not widely used.
4. Configuration would be easier to manage as it would live under config/. At the moment some configuration lives in the dev.exs file directly.
5. Would pick up changes automatically without having to restart the server manually.

Some of this work has already started on #34. For example dev and test environments now reuse the same migrations.

Admin UI

We need an admin section in which we can see, manage and navigate through all of the existing errors. We should also be able to mark errors as open or close depending on whether they have been fixed or not. By default closed errors should be hidden to avoid unneccessary noise.

Count number of occurrences

Include the number of occurrences both in the dashboard and in the error detail. This may be useful information to know how frequent errors are.

Notificate errors by email or Telegram

Hi!
First of all, just to say thank you all for this awesome and really great project that ease to track errors without building a heavy infrastructure and a lot of configuration. Congratulations! It works really nice just installing it and with the initial configuration steps you give in the documentation.

I am really interested in the notification of errors, because it can be really useful. I will implement it in a project handling the events emitted by ErrorTracker.Telemetry.

I just want to know if you are interested in having it implemented in ErrorTracker or if you prefer to keep it out by the moment:

1. If you want it implemented in ErrorTracker, I can directly fork the project and start from there following your conventions, etc.
2. If you want it outside of ErrorTracker, I will probably create a simple and easy package that implement this feature.

In case of 2, I would like to confirm if you agree with naming the package using error_tracker_ prefix.

In any case, 1 or 2, my idea and the roadmap in my head (I have not draw it yet!) is:

1. Implement the handling of events.
2. Let the user the possibility to send notifications by email.
3. ... and then by Telegram.

I really prefer 3, because I use it more than the email, but I think it I will need to research and study more the implementation of that part.

Of course, any advice you can give is more than welcome! So I am going to wait for you answers ❤️, I am no in any hurry, so I can do it with calm in any of the cases.

Again, thank you very much for free and maintain this project!

Regards

Migration error when using CockroachDB

When trying to run the migration with Postgrex & CockroachDB, the following error occurs:

[info] execute "INSERT INTO public.error_tracker_meta (key, value)\nVALUES ('migration_version', '2'), ('migration_timestamp', 1723522363)\nON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value\n"
** (Postgrex.Error) ERROR 42804 (datatype_mismatch) VALUES types int and string cannot be matched

    query: INSERT INTO public.error_tracker_meta (key, value)
VALUES ('migration_version', '2'), ('migration_timestamp', 1723522363)
ON CONFLICT (key) DO UPDATE SET value = EXCLUDED.value

I am wondering if we could rewrite it following this pattern, it will probably fix the issue.

INSERT INTO t (a, b, ..., n)
VALUES ('1', '2', ..., 'n')
ON CONFLICT DO UPDATE SET
  a = '1',
  b = '2',
  ...
  n = 'n';

Handle LiveView exceptions

At the moment we are handling Phoenix controller exception but not LiveView's. We can use the telemetry events to handle those. The relevant events are:

• [:phoenix, :live_view, :mount, :exception]
• [:phoenix, :live_view, :handle_params, :exception]
• [:phoenix, :live_view, :handle_event, :exception]
• [:phoenix, :live_view, :render, :exception]

And for LiveComponents:

• [:phoenix, :live_component, :update, :exception]
• [:phoenix, :live_component, :handle_event, :exception]

We should also take a look at :start events to set the error context as appropriate.

Documentation

We need to improve the code documentation and README for the initial release so others know how to set up the error tracker and work with it.

make the landing page configurable

Every time I land on the dashboard page I have to click on the resolved/unresolved dropdown... It would be amazing to be able to config the default view to default to only showing the unresolved errors.

I know you can do it via a url like so ?status=unresolved but I often find myself typing in the url.