An error occurred fetching the project authors.
  1. 01 Jun, 2021 1 commit
  2. 23 Apr, 2021 1 commit
  3. 30 Mar, 2021 1 commit
    • Sean McGivern's avatar
      Allow Sentry processors to be used directly or in before_send · 5bdcdb97
      Sean McGivern authored
      We want to upgrade the version of the Sentry gem we're currently using
      to the latest version. However, this makes some breaking changes. One of
      the biggest for our purposes is that it no longer supports processors -
      these were classes to pre-process the event hash before sending to
      Sentry.
      
      In the latest version, these are no longer available, but we can still
      use any logic we like in a custom `before_send` hook. So we can manually
      chain our existing processors there. However, there's a catch:
      processors in the current version take an event hash, but the
      `before_send` hook takes an Event object. (Raven::Event in the current
      version, Sentry::Event in the new one.)
      
      This change adds a feature flag - sentry_processors_before_send - that
      defaults to off. When it's off, we use the processors as we do now. When
      it's on:
      
      1. All the processors become no-ops when called as processors.
      2. We enable them in a `before_send` chain through a different
         interface.
      
      Because they take a different type of argument, this makes the
      processors in this change a little ugly. We can tidy that up once we've
      validated this feature flag in production, even before upgrading the
      gem. We also add specs to test each processor both with and without the
      feature flag enabled.
      5bdcdb97
  4. 25 Mar, 2021 2 commits
  5. 09 Feb, 2021 2 commits
  6. 08 Feb, 2021 1 commit
  7. 05 Jan, 2021 1 commit
    • Heinrich Lee Yu's avatar
      Fix Sentry tracking of SQL queries · 7c502e91
      Heinrich Lee Yu authored
      Moves the hook to the before_send so that this would be run for
      exceptions that are automatically caught by Sentry Raven.
      
      This also checks Exception#cause so we handle timeouts that happen in
      view templates where the exceptions would be wrapped in an
      ActionView::Template::Error
      7c502e91
  8. 23 Oct, 2020 3 commits
  9. 22 Oct, 2020 1 commit
  10. 21 Oct, 2020 1 commit
    • Mehmet Emin INAC's avatar
      Normalize the SQL queries before sending them to Sentry · 4abc7fcd
      Mehmet Emin INAC authored
      To prevent sending some sensitive information, we need to normalize the
      SQL queries before we send them to Sentry. To do so, we decided to use
      the gem called `pg_query` which compiles some parts of the PostgreSQL
      database to make it possible to parse SQL queries.
      4abc7fcd
  11. 20 Oct, 2020 2 commits
  12. 07 Jul, 2020 1 commit
    • Sean McGivern's avatar
      Allow setting extra Sentry tags from environment · 56f50aff
      Sean McGivern authored
      When GitLab reports an exception from Sentry, it adds tags of
      'correlation_id', 'locale', and 'program'. This allows further tags to
      be specified by the administrator in the GITLAB_SENTRY_EXTRA_TAGS
      environment variable.
      
      This variable must be a JSON-encoded hash of tags to send on every
      Sentry event. If it fails to decode from JSON and convert to a hash, it
      will simply be empty.
      56f50aff
  13. 23 Jun, 2020 1 commit
  14. 11 Jun, 2020 2 commits
    • Sean McGivern's avatar
      Filter Sidekiq arguments in log files · 8dbf036e
      Sean McGivern authored
      Sidekiq arguments can contain sensitive data. As with Sentry (in the
      previous commit), we should no emit sensitive arguments in log files.
      8dbf036e
    • Sean McGivern's avatar
      Filter Sidekiq arguments in Sentry · 59721a9d
      Sean McGivern authored
      Filter out sensitive Sidekiq arguments from being sent to Sentry. By
      default, only numeric arguments are sent. Overrides are possible for
      individual worker classes if they have safe non-numeric arguments.
      59721a9d
  15. 29 May, 2020 1 commit
  16. 06 Feb, 2020 1 commit
  17. 13 Dec, 2019 2 commits
    • Aleksei Lipniagov's avatar
      Rename Gitlab::Sentry into Gitlab::ErrorTracking · 035e7359
      Aleksei Lipniagov authored
      Gitlab::Sentry does not reflect the purpose of the class, it needs more
      generic name which service-agnostic.
      035e7359
    • Kamil Trzciński's avatar
      Refactor Sentry handling · 1ee162b6
      Kamil Trzciński authored
      Rename methods of Sentry class:
      - `track_acceptable_exception` => `track_exception`: we just want
         to capture exception
      - `track_exception` => `track_and_raise_for_dev_exception`: as said,
      - `track_and_raise_exception` => we want to capture
        and re-raise exception
      
      Update exception tracking
      
      - Remove `extra:` and instead accept hash,
      - Update documentation to include the best practices,
      - Remove manual logging of exceptions
      1ee162b6
  18. 17 Sep, 2019 1 commit
  19. 22 Aug, 2019 1 commit
  20. 19 Aug, 2019 1 commit
  21. 13 May, 2019 1 commit
    • Bob Van Landuyt's avatar
      Add correlation id to all sentry errors · 4c2f6814
      Bob Van Landuyt authored
      Before this, we were only adding the correlation id to the "acceptable
      exceptions" which we handle in code.
      
      But we need to add it to the default raven context so the information
      would be available for uncaught exceptions.
      4c2f6814
  22. 18 Apr, 2019 2 commits
  23. 06 Dec, 2018 1 commit
  24. 14 Nov, 2018 1 commit
  25. 17 Apr, 2018 1 commit
  26. 31 Aug, 2017 1 commit