Skip to content
Snippets Groups Projects
This project is mirrored from https://github.com/metabase/metabase. Pull mirroring updated .
  1. Oct 14, 2024
  2. Oct 11, 2024
  3. Oct 10, 2024
    • appleby's avatar
      Relax concat args to allow any ExpressionArg (#48506) · c16d05a0
      appleby authored
      * Relax the arg types to ExpressionArg for concat expressions in the legacy schema
      
      Relax the arg types to ExpressionArg for concat since many DBs allow to concatenate non-string types. This also aligns
      with the corresponding MLv2 schema and with the reference docs we publish.
      
      Fixes #39439
      
      * Add nested concat schema tests
      
      * Add nested-concat query-processor tests
      Unverified
      c16d05a0
    • dpsutton's avatar
      Always startup prometheus metrics (#48547) · 2410012a
      dpsutton authored
      * Always startup prometheus metrics
      
      previously only started up when a port was provided
      
      ```
      MB_PROMETHEUS_SERVER_PORT=9191 java -jar metabase.jar
      ```
      
      But these counters are useful to be included in anonymous stats. So
      let's start up the collectors and then we can get their values like:
      
      ```clojure
      prometheus=> (dotimes [_ 500] (inc :metabase-email/messages))
      nil
      ;; prometheus/value is iapetos.core/value here
      prometheus=> (-> system :registry :metabase-email/messages prometheus/value)
      501.0
      ```
      
      * rename `metabase.analytics.prometheus/inc` to `inc!`
      
      it side effects a value and now no longer shadows `clojure.core/inc` so
      we're all happy
      Unverified
      2410012a
    • Ngoc Khuat's avatar
      [Notification] System event notification (#47857) · fc43d3cd
      Ngoc Khuat authored
      * [Notification] Notification and subscription (#47707)
      
      * [Notification] Notification and subscription (#47707)
      
      * [Notification] Handlers + recipients (#47759)
      
      * [Notification] Channel template table and model (#47782)
      
      * [Notification] Render system event emails (#47859)
      
      * [Notification] Strict type for channel template and notification recipient (#47910)
      
      * [Notification] Event hydration (#47953)
      
      * [Notification] Send asynchronously (#48200)
      Unverified
      fc43d3cd
  4. Oct 09, 2024
  5. Oct 08, 2024
  6. Oct 07, 2024
  7. Oct 04, 2024
  8. Oct 03, 2024
  9. Oct 01, 2024
  10. Sep 30, 2024
    • Noah Moss's avatar
    • John Swanson's avatar
      Do not cache all token check failures (#48147) · 0ef2052f
      John Swanson authored
      * Do not cache all token check failures
      
      We want to cache token checks to avoid an issue where we repeatedly ask
      the store "hey, is this token valid?? is this token valid?? is this
      token valid??" for the same token.
      
      However, transient errors can also occur. For example, maybe a network
      issue causes the HTTP request to fail entirely. In this case, if we
      cache the result, the user needs to restart metabase (or wait 5 minutes
      until the cache is cleared) before they can attempt to validate their
      token again.
      
      This PR moves the cache logic deeper into the stack. We want to cache
      "successful" responses from the store API - cases where the store has
      told us categorically that the token is or is not valid. We don't want
      or need to cache other things that might happen. Maybe your token isn't
      the right length - we can recalculate that, it's ok. Maybe you get a 503
      error from the Store - we should let you retry. Maybe your network is
      having issues and you can't contact the Store at all - again, we should
      let you retry.
      
      The one potential issue I see here is that if the store goes down, we'll
      massively increase the number of requests we send to the store,
      potentially making it harder to recover. If this is a concern, I can add
      a circuit breaker: if we repeatedly get errors back from the store, back
      off and stop making requests for a while.
      
      * Add a circuit breaker to store API requests
      
      In the pathological case where the store goes down for >5 minutes, the
      cache will expire and all instances everywhere will start repeatedly
      making requests for token validation at once. This might make recovering
      from an outage more difficult.
      
      This adds a circuit breaker around the API request. If the call
      repeatedly throws (5XX errors, socket timeouts, etc.) then we'll pause
      for 1 minute, during which time all calls to token validation will
      immediately fail without making any request to the API.
      
      After one minute, we'll allow one request through to the API. If it
      succeeds, we'll go back to normal operation. Otherwise, we'll wait
      another minute.
      Unverified
      0ef2052f
    • Noah Moss's avatar
  11. Sep 27, 2024
Loading