{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":10100635,"defaultBranch":"main","name":"appsignal-ruby","ownerLogin":"appsignal","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2013-05-16T12:25:54.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/3984134?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1717409349.0","currentOid":""},"activityList":{"items":[{"before":"514f4f220c49f470e50e90d77a3542d10ec4ee30","after":"d0db72b77e8404f5725565f06c64bfab0bb84dab","ref":"refs/heads/rack-response-code","pushedAt":"2024-06-03T10:27:04.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Report request response status for Rails apps\n\nWe can now report the response status as a `response_status` tag and\nmetric. Previously, due to the position of the Rails middleware, this\nwas unreliable and wouldn't always report the real status code if other\nmiddleware in the stack that are run after ours returned another status.\n\nThis is part of issue #183, but only implements it now for Rails apps\nand apps using the `Appsignal::Rack::EventHandler` manually. We'll need\nto update other instrumentations for Rack, Sinatra, Padrino, Grape, etc.\nto use this new EventHandler, so they can also benefit from this new\nresponse status tag and metric.","shortMessageHtmlLink":"Report request response status for Rails apps"}},{"before":"d108a583b006bde91ff219c8565ced796a0a9274","after":"ca53b04360ae123498640d043ee7ba74efc4b295","ref":"refs/heads/rack-event-handler","pushedAt":"2024-06-03T10:26:55.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve Rails/Rack request instrumentation\n\nRework the Rails instrumentation to use the Rack::Events module to start\nand complete the transaction at the very start and end of the request.\nA new middleware is added at the very top of the middleware stack to\nstart and complete the transaction.\n\nThis allows us to instrument more of the request's duration, as we're\nnow at the very start and end of the request handling. We will now\nreport the time the request has spend handling any other middleware.\nThis will be visible with a new `process_request.rack` event.\n\nTo make sure we always close the transaction, listen for the `on_finish`\nevent, but also register a last resort \"after_reply\" callback. This\ncallback is supported by web servers like Puma and Unicorn. If it's\ncalled when a transaction is active, it will close it, preventing\ntransactions to span multiple requests. If no transaction is active, it\nwill do nothing.\n\nMoving forward, I'd like to update our Rack, Sinatra, Padrino, Grape,\netc. instrumentations to use this EventHandler middleware too, which\nwill be a bit more work, because some require users to manually add\nmiddleware. When they all use the same EventHandler, we have one place\nto start and complete transactions, and issues like\nhttps://github.com/appsignal/appsignal-ruby/issues/289 cannot happen\nagain in the future.\n\nPreviously, our only Rails instrumentation was positioned after the\nDebugExceptions middleware, just in time to catch any errors before the\nRails error middleware showed a nice error/debug page. This wouldn't\nshow the complete picture in request duration.\n\nThe original Rails instrumentation middleware will remain to report\nerrors and Rails specific metadata. This cannot be part of the\nEventHandler, without overloading it with responsibilities, and for\nRails error reporting we need to be right after the DebugExceptions\nmiddleware before errors are no longer bubbled up in the stack.\n\nInstead of the transaction ID being the request ID, set a new\n`request_id` tag to not break existing behavior.\n\nPart of https://github.com/appsignal/appsignal-ruby/issues/329","shortMessageHtmlLink":"Improve Rails/Rack request instrumentation"}},{"before":"52fc3b5a6cd7b8f8e462b331a958648d4c109ccc","after":"d108a583b006bde91ff219c8565ced796a0a9274","ref":"refs/heads/rack-event-handler","pushedAt":"2024-06-03T10:25:28.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve Rails/Rack request instrumentation\n\nRework the Rails instrumentation to use the Rack::Events module to start\nand complete the transaction at the very start and end of the request.\nA new middleware is added at the very top of the middleware stack to\nstart and complete the transaction.\n\nThis allows us to instrument more of the request's duration, as we're\nnow at the very start and end of the request handling. We will now\nreport the time the request has spend handling any other middleware.\nThis will be visible with a new `process_request.rack` event.\n\nTo make sure we always close the transaction, listen for the `on_finish`\nevent, but also register a last resort \"after_reply\" callback. This\ncallback is supported by web servers like Puma and Unicorn. If it's\ncalled when a transaction is active, it will close it, preventing\ntransactions to span multiple requests. If no transaction is active, it\nwill do nothing.\n\nMoving forward, I'd like to update our Rack, Sinatra, Padrino, Grape,\netc. instrumentations to use this EventHandler middleware too, which\nwill be a bit more work, because some require users to manually add\nmiddleware. When they all use the same EventHandler, we have one place\nto start and complete transactions, and issues like\nhttps://github.com/appsignal/appsignal-ruby/issues/289 cannot happen\nagain in the future.\n\nPreviously, our only Rails instrumentation was positioned after the\nDebugExceptions middleware, just in time to catch any errors before the\nRails error middleware showed a nice error/debug page. This wouldn't\nshow the complete picture in request duration.\n\nThe original Rails instrumentation middleware will remain to report\nerrors and Rails specific metadata. This cannot be part of the\nEventHandler, without overloading it with responsibilities, and for\nRails error reporting we need to be right after the DebugExceptions\nmiddleware before errors are no longer bubbled up in the stack.\n\nInstead of the transaction ID being the request ID, set a new\n`request_id` tag to not break existing behavior.\n\nPart of https://github.com/appsignal/appsignal-ruby/issues/329","shortMessageHtmlLink":"Improve Rails/Rack request instrumentation"}},{"before":"211ab2f1f1cdb7fa2d8b9c60f2139b742ccc91c9","after":"514f4f220c49f470e50e90d77a3542d10ec4ee30","ref":"refs/heads/rack-response-code","pushedAt":"2024-06-03T10:11:48.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Report request response status for Rails apps\n\nWe can now report the response status as a `response_status` tag and\nmetric. Previously, due to the position of the Rails middleware, this\nwas unreliable and wouldn't always report the real status code if other\nmiddleware in the stack that are run after ours returned another status.\n\nThis is part of issue #183, but only implements it now for Rails apps\nand apps using the `Appsignal::Rack::EventHandler` manually. We'll need\nto update other instrumentations for Rack, Sinatra, Padrino, Grape, etc.\nto use this new EventHandler, so they can also benefit from this new\nresponse status tag and metric.","shortMessageHtmlLink":"Report request response status for Rails apps"}},{"before":null,"after":"211ab2f1f1cdb7fa2d8b9c60f2139b742ccc91c9","ref":"refs/heads/rack-response-code","pushedAt":"2024-06-03T10:09:09.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Report request response status for Rails apps\n\nWe can now report the response status as a `response_status` tag and\nmetric. Previously, due to the position of the Rails middleware, this\nwas unreliable and wouldn't always report the real status code if other\nmiddleware in the stack that are run after ours returned another status.\n\nThis is part of issue #183, but only implements it now for Rails apps\nand apps using the `Appsignal::Rack::EventHandler` manually. We'll need\nto update other instrumentations for Rack, Sinatra, Padrino, Grape, etc.\nto use this new EventHandler, so they can also benefit from this new\nresponse status tag and metric.","shortMessageHtmlLink":"Report request response status for Rails apps"}},{"before":"af5fb43a51f370c99e9ebf4fcaa9707706f90a4f","after":"52fc3b5a6cd7b8f8e462b331a958648d4c109ccc","ref":"refs/heads/rack-event-handler","pushedAt":"2024-05-31T09:58:50.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve Rails/Rack request instrumentation\n\nRework the Rails instrumentation to use the Rack::Events module to start\nand complete the transaction at the very start and end of the request.\nA new middleware is added at the very top of the middleware stack to\nstart and complete the transaction.\n\nThis allows us to instrument more of the request's duration, as we're\nnow at the very start and end of the request handling. We will now\nreport the time the request has spend handling any other middleware.\nThis will be visible with a new `process_request.rack` event.\n\nTo make sure we always close the transaction, listen for the `on_finish`\nevent, but also register a last resort \"after_reply\" callback. This\ncallback is supported by web servers like Puma and Unicorn. If it's\ncalled when a transaction is active, it will close it, preventing\ntransactions to span multiple requests. If no transaction is active, it\nwill do nothing.\n\nMoving forward, I'd like to update our Rack, Sinatra, Padrino, Grape,\netc. instrumentations to use this EventHandler middleware too, which\nwill be a bit more work, because some require users to manually add\nmiddleware. When they all use the same EventHandler, we have one place\nto start and complete transactions, and issues like\nhttps://github.com/appsignal/appsignal-ruby/issues/289 cannot happen\nagain in the future.\n\nPreviously, our only Rails instrumentation was positioned after the\nDebugExceptions middleware, just in time to catch any errors before the\nRails error middleware showed a nice error/debug page. This wouldn't\nshow the complete picture in request duration.\n\nThe original Rails instrumentation middleware will remain to report\nerrors and Rails specific metadata. This cannot be part of the\nEventHandler, without overloading it with responsibilities, and for\nRails error reporting we need to be right after the DebugExceptions\nmiddleware before errors are no longer bubbled up in the stack.\n\nInstead of the transaction ID being the request ID, set a new\n`request_id` tag to not break existing behavior.\n\nPart of https://github.com/appsignal/appsignal-ruby/issues/329","shortMessageHtmlLink":"Improve Rails/Rack request instrumentation"}},{"before":"a3d920df69cbcee6ba53e86e8e07162e4a54eeda","after":"af5fb43a51f370c99e9ebf4fcaa9707706f90a4f","ref":"refs/heads/rack-event-handler","pushedAt":"2024-05-31T08:26:35.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve Rails/Rack request instrumentation\n\nRework the Rails instrumentation to use the Rack::Events module to start\nand complete the transaction at the very start and end of the request.\nA new middleware is added at the very top of the middleware stack to\nstart and complete the transaction.\n\nThis allows us to instrument more of the request's duration, as we're\nnow at the very start and end of the request handling. We will now\nreport the time the request has spend handling any other middleware.\nThis will be visible with a new `process_request.rack` event.\n\nTo make sure we always close the transaction, listen for the `on_finish`\nevent, but also register a last resort \"after_reply\" callback. This\ncallback is supported by web servers like Puma and Unicorn. If it's\ncalled when a transaction is active, it will close it, preventing\ntransactions to span multiple requests. If no transaction is active, it\nwill do nothing.\n\nMoving forward, I'd like to update our Rack, Sinatra, Padrino, Grape,\netc. instrumentations to use this EventHandler middleware too, which\nwill be a bit more work, because some require users to manually add\nmiddleware. When they all use the same EventHandler, we have one place\nto start and complete transactions, and issues like\nhttps://github.com/appsignal/appsignal-ruby/issues/289 cannot happen\nagain in the future.\n\nPreviously, our only Rails instrumentation was positioned after the\nDebugExceptions middleware, just in time to catch any errors before the\nRails error middleware showed a nice error/debug page. This wouldn't\nshow the complete picture in request duration.\n\nThe original Rails instrumentation middleware will remain to report\nerrors and Rails specific metadata. This cannot be part of the\nEventHandler, without overloading it with responsibilities, and for\nRails error reporting we need to be right after the DebugExceptions\nmiddleware before errors are no longer bubbled up in the stack.\n\nOne downside of having the Rack EventHandler create the transaction is\nthat we can no longer use the ActionDispatch (Rails) request ID as the\ntransaction ID. I tried overwriting the `request_id` tag by setting it\nmanually, but this doesn't work. If we merge this as-is we might break\nany linking we do in our frontend between the request id tag and logs.\nI'll start working on a change in our processor for this.\n\nPart of https://github.com/appsignal/appsignal-ruby/issues/329","shortMessageHtmlLink":"Improve Rails/Rack request instrumentation"}},{"before":"a225a78edab6e77270a644bfa87a6efcfd597384","after":"a3d920df69cbcee6ba53e86e8e07162e4a54eeda","ref":"refs/heads/rack-event-handler","pushedAt":"2024-05-31T08:23:10.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve Rails/Rack request instrumentation\n\nRework the Rails instrumentation to use the Rack::Events module to start\nand complete the transaction at the very start and end of the request.\nA new middleware is added at the very top of the middleware stack to\nstart and complete the transaction.\n\nThis allows us to instrument more of the request's duration, as we're\nnow at the very start and end of the request handling. We will now\nreport the time the request has spend handling any other middleware.\nThis will be visible with a new `process_request.rack` event.\n\nTo make sure we always close the transaction, listen for the `on_finish`\nevent, but also register a last resort \"after_reply\" callback. This\ncallback is supported by web servers like Puma and Unicorn. If it's\ncalled when a transaction is active, it will close it, preventing\ntransactions to span multiple requests. If no transaction is active, it\nwill do nothing.\n\nMoving forward, I'd like to update our Rack, Sinatra, Padrino, Grape,\netc. instrumentations to use this EventHandler middleware too, which\nwill be a bit more work, because some require users to manually add\nmiddleware. When they all use the same EventHandler, we have one place\nto start and complete transactions, and issues like\nhttps://github.com/appsignal/appsignal-ruby/issues/289 cannot happen\nagain in the future.\n\nPreviously, our only Rails instrumentation was positioned after the\nDebugExceptions middleware, just in time to catch any errors before the\nRails error middleware showed a nice error/debug page. This wouldn't\nshow the complete picture in request duration.\n\nThe original Rails instrumentation middleware will remain to report\nerrors and Rails specific metadata. This cannot be part of the\nEventHandler, without overloading it with responsibilities, and for\nRails error reporting we need to be right after the DebugExceptions\nmiddleware before errors are no longer bubbled up in the stack.\n\nOne downside of having the Rack EventHandler create the transaction is\nthat we can no longer use the ActionDispatch (Rails) request ID as the\ntransaction ID. I tried overwriting the `request_id` tag by setting it\nmanually, but this doesn't work. If we merge this as-is we might break\nany linking we do in our frontend between the request id tag and logs.\nI'll start working on a change in our processor for this.\n\nPart of https://github.com/appsignal/appsignal-ruby/issues/329","shortMessageHtmlLink":"Improve Rails/Rack request instrumentation"}},{"before":"0fe2edc0141fdebe410829ea3df43ed5823a9330","after":"a225a78edab6e77270a644bfa87a6efcfd597384","ref":"refs/heads/rack-event-handler","pushedAt":"2024-05-31T08:22:39.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve Rails/Rack request instrumentation\n\nRework the Rails instrumentation to use the Rack::Events module to start\nand complete the transaction at the very start and end of the request.\nA new middleware is added at the very top of the middleware stack to\nstart and complete the transaction.\n\nThis allows us to instrument more of the request's duration, as we're\nnow at the very start and end of the request handling. We will now\nreport the time the request has spend handling any other middleware.\nThis will be visible with a new `process_request.rack` event.\n\nTo make sure we always close the transaction, listen for the `on_finish`\nevent, but also register a last resort \"after_reply\" callback. This\ncallback is supported by web servers like Puma and Unicorn. If it's\ncalled when a transaction is active, it will close it, preventing\ntransactions to span multiple requests. If no transaction is active, it\nwill do nothing.\n\nMoving forward, I'd like to update our Rack, Sinatra, Padrino, Grape,\netc. instrumentations to use this EventHandler middleware too, which\nwill be a bit more work, because some require users to manually add\nmiddleware. When they all use the same EventHandler, we have one place\nto start and complete transactions, and issues like\nhttps://github.com/appsignal/appsignal-ruby/issues/289 cannot happen\nagain in the future.\n\nPreviously, our only Rails instrumentation was positioned after the\nDebugExceptions middleware, just in time to catch any errors before the\nRails error middleware showed a nice error/debug page. This wouldn't\nshow the complete picture in request duration.\n\nThe original Rails instrumentation middleware will remain to report\nerrors and Rails specific metadata. This cannot be part of the\nEventHandler, without overloading it with responsibilities, and for\nRails error reporting we need to be right after the DebugExceptions\nmiddleware before errors are no longer bubbled up in the stack.\n\nOne downside of having the Rack EventHandler create the transaction is\nthat we can no longer use the ActionDispatch (Rails) request ID as the\ntransaction ID. I tried overwriting the `request_id` tag by setting it\nmanually, but this doesn't work. If we merge this as-is we might break\nany linking we do in our frontend between the request id tag and logs.\nI'll start working on a change in our processor for this.\n\nPart of https://github.com/appsignal/appsignal-ruby/issues/329","shortMessageHtmlLink":"Improve Rails/Rack request instrumentation"}},{"before":"fa97aa1f877793350f9333916b27ac287e3c472e","after":"0fe2edc0141fdebe410829ea3df43ed5823a9330","ref":"refs/heads/rack-event-handler","pushedAt":"2024-05-31T07:52:42.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve Rails/Rack request instrumentation\n\nRework the Rails instrumentation to use the Rack::Events module to start\nand complete the transaction at the very start and end of the request.\nA new middleware is added at the very top of the middleware stack to\nstart and complete the transaction.\n\nThis allows us to instrument more of the request's duration, as we're\nnow at the very start and end of the request handling. We will now\nreport the time the request has spend handling any other middleware.\nThis will be visible with a new `process_request.rack` event.\n\nTo make sure we always close the transaction, listen for the `on_finish`\nevent, but also register a last resort \"after_reply\" callback. This\ncallback is supported by web servers like Puma and Unicorn. If it's\ncalled when a transaction is active, it will close it, preventing\ntransactions to span multiple requests. If no transaction is active, it\nwill do nothing.\n\nMoving forward, I'd like to update our Rack, Sinatra, Padrino, Grape,\netc. instrumentations to use this EventHandler middleware too, which\nwill be a bit more work, because some require users to manually add\nmiddleware. When they all use the same EventHandler, we have one place\nto start and complete transactions, and issues like\nhttps://github.com/appsignal/appsignal-ruby/issues/289 cannot happen\nagain in the future.\n\nPreviously, our only Rails instrumentation was positioned after the\nDebugExceptions middleware, just in time to catch any errors before the\nRails error middleware showed a nice error/debug page. This wouldn't\nshow the complete picture in request duration.\n\nThe original Rails instrumentation middleware will remain to report\nerrors and Rails specific metadata. This cannot be part of the\nEventHandler, without overloading it with responsibilities, and for\nRails error reporting we need to be right after the DebugExceptions\nmiddleware before errors are no longer bubbled up in the stack.\n\nTODO: SPLIT COMMIT:\nWe can now report the response status as a `response_status` tag and\nmetric. Previously, due to the position of the Rails middleware, this\nwas unreliable and wouldn't always report the real status code if other\nmiddleware in the stack returned another status.\n\nThis is part of issue\nhttps://github.com/appsignal/appsignal-ruby/issues/183, but only\nimplements it now for Rails apps and apps using the\n`Appsignal::Rack::EventHandler` manually. We'll need to update other\ninstrumentations for Rack, Sinatra, Padrino, Grape, etc. to use this new\nEventHandler, so they can also benefit from this new response status tag\nand metric.\n\nTODO:\n\n- How to report the request_id? Can't overwrite the tag\n- Remove the `request_id2` tag","shortMessageHtmlLink":"Improve Rails/Rack request instrumentation"}},{"before":null,"after":"fa97aa1f877793350f9333916b27ac287e3c472e","ref":"refs/heads/rack-event-handler","pushedAt":"2024-05-30T20:46:40.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"WIP","shortMessageHtmlLink":"WIP"}},{"before":"704a7d29ae428f93549000a2c606bff948040c96","after":"2035a1f91efed147e6e05271003eef3ae1c351bc","ref":"refs/heads/main","pushedAt":"2024-05-24T16:06:04.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve AppSignal loaded log (#1087)","shortMessageHtmlLink":"Improve AppSignal loaded log (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2312865002\" data-permission-text=\"Title is private\" data-url=\"https://github.com/appsignal/appsignal-ruby/issues/1087\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/appsignal/appsignal-ruby/pull/1087/hovercard\" href=\"https://github.com/appsignal/appsignal-ruby/pull/1087\">#1087</a>)"}},{"before":"e6d98f5143710f76e92454a0b8d1a18be3cefcb6","after":"704a7d29ae428f93549000a2c606bff948040c96","ref":"refs/heads/main","pushedAt":"2024-05-24T16:05:25.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Log error when probes iteration takes too long (#1088)","shortMessageHtmlLink":"Log error when probes iteration takes too long (<a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2314633270\" data-permission-text=\"Title is private\" data-url=\"https://github.com/appsignal/appsignal-ruby/issues/1088\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/appsignal/appsignal-ruby/pull/1088/hovercard\" href=\"https://github.com/appsignal/appsignal-ruby/pull/1088\">#1088</a>)"}},{"before":"8a58f4d9575f361d668a9ffdf5c78e9f47778fe1","after":"e6d98f5143710f76e92454a0b8d1a18be3cefcb6","ref":"refs/heads/main","pushedAt":"2024-05-24T16:01:39.000Z","pushType":"pr_merge","commitsCount":3,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Merge pull request #1085 from appsignal/heartbeat-docs","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2308231401\" data-permission-text=\"Title is private\" data-url=\"https://github.com/appsignal/appsignal-ruby/issues/1085\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/appsignal/appsignal-ruby/pull/1085/hovercard\" href=\"https://github.com/appsignal/appsignal-ruby/pull/1085\">#1085</a> from appsignal/heartbeat-docs"}},{"before":"f5320470f0bb9ffe5a87b36b33e0cebe360b3097","after":"a06105cb40e637e3b0020b626da49892c3c438e7","ref":"refs/heads/slow-probes-error","pushedAt":"2024-05-24T07:25:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Log error when probes iteration takes too long\n\nLog an error when the total probes iteration takes more than a minute.\nIt's the 'minutely' probes process, and doesn't report accurate minutely\nmetrics if each iteration takes more than a minute.\n\nCloses #814","shortMessageHtmlLink":"Log error when probes iteration takes too long"}},{"before":null,"after":"f5320470f0bb9ffe5a87b36b33e0cebe360b3097","ref":"refs/heads/slow-probes-error","pushedAt":"2024-05-24T07:21:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Log error when probes iteration takes too long\n\nLog an error when the total probes iteration takes more than a minute.\nIt's the 'minutely' probes process, and doesn't report accurate minutely\nmetrics if each iteration takes more than a minute.\n\nCloses #814","shortMessageHtmlLink":"Log error when probes iteration takes too long"}},{"before":null,"after":"277fa79d40532ee8e0935d0e22c5123d421ee4dd","ref":"refs/heads/improve-start-log","pushedAt":"2024-05-23T12:51:52.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Improve AppSignal loaded log\n\nIt would say AppSignal \"started\", even if the integration wasn't\nactually configured to start and be active for the app environment.\n\nChange the phrase to say \"loading\" so it's clear it's being loaded /\ninitialized, rather than AppSignal becoming active.\n\n[skip changeset] as it's not worth mentioning this change in a debug\nlog message.\n\nCloses https://github.com/appsignal/support/issues/188","shortMessageHtmlLink":"Improve AppSignal loaded log"}},{"before":"973d87c0feba7d09dd2281a44baa40219f4bcfdd","after":null,"ref":"refs/heads/probes-spec","pushedAt":"2024-05-23T07:34:19.000Z","pushType":"branch_deletion","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"}},{"before":"5142bf2ca52ec43f3d8dce00a89166933324a937","after":"8a58f4d9575f361d668a9ffdf5c78e9f47778fe1","ref":"refs/heads/main","pushedAt":"2024-05-23T07:34:09.000Z","pushType":"pr_merge","commitsCount":3,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Merge pull request #1086 from appsignal/probes-spec\n\nImprove probe specs","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2312156373\" data-permission-text=\"Title is private\" data-url=\"https://github.com/appsignal/appsignal-ruby/issues/1086\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/appsignal/appsignal-ruby/pull/1086/hovercard\" href=\"https://github.com/appsignal/appsignal-ruby/pull/1086\">#1086</a> from appsignal/probes-spec"}},{"before":null,"after":"973d87c0feba7d09dd2281a44baa40219f4bcfdd","ref":"refs/heads/probes-spec","pushedAt":"2024-05-23T07:23:08.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Use speed_up_tests helper in probes spec\n\nInstead of manually stubbing the method call, use the helper that stubs\nit the same way for every spec that needs it.\n\n[skip changeset]","shortMessageHtmlLink":"Use speed_up_tests helper in probes spec"}},{"before":"0c0d60b569832cc27a6a3d86510132a0bdcea300","after":"7de4086d706d43ac3f860f0e91916a76ab3302ef","ref":"refs/heads/heartbeat-docs","pushedAt":"2024-05-21T13:49:34.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Add documentation for heartbeat functionality\n\nAdd documentation to describe the heartbeat functionality in the Ruby\ngem's API docs.","shortMessageHtmlLink":"Add documentation for heartbeat functionality"}},{"before":"972a5aac86d93f70e6045faca1144e7ad39547ca","after":"0c0d60b569832cc27a6a3d86510132a0bdcea300","ref":"refs/heads/heartbeat-docs","pushedAt":"2024-05-21T12:49:01.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Add documentation for heartbeat functionality\n\nAdd documentation to describe the heartbeat functionality in the Ruby\ngem's API docs.","shortMessageHtmlLink":"Add documentation for heartbeat functionality"}},{"before":null,"after":"972a5aac86d93f70e6045faca1144e7ad39547ca","ref":"refs/heads/heartbeat-docs","pushedAt":"2024-05-21T12:48:04.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"tombruijn","name":"Tom de Bruijn","path":"/tombruijn","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/282402?s=80&v=4"},"commit":{"message":"Add documentation for heartbeat functionality\n\nAdd documentation to describe the heartbeat functionality in the Ruby\ngem's API docs.","shortMessageHtmlLink":"Add documentation for heartbeat functionality"}},{"before":"0656cb808a660872ba866126fe9d96ec6f99012f","after":"5142bf2ca52ec43f3d8dce00a89166933324a937","ref":"refs/heads/main","pushedAt":"2024-05-14T12:25:20.000Z","pushType":"push","commitsCount":1,"pusher":{"login":"unflxw","name":"Noemi","path":"/unflxw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45180344?s=80&v=4"},"commit":{"message":"Publish package v3.7.5\n\nUpdate version number and CHANGELOG.md.","shortMessageHtmlLink":"Publish package v3.7.5"}},{"before":"9dd041de07049155f51ea3c9d0d74e8b3e0c50f3","after":"0656cb808a660872ba866126fe9d96ec6f99012f","ref":"refs/heads/main","pushedAt":"2024-05-14T12:23:04.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"unflxw","name":"Noemi","path":"/unflxw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45180344?s=80&v=4"},"commit":{"message":"Merge pull request #1084 from appsignal/bump-agent-0.35.10\n\nBump agent to version 0.35.10","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2295285967\" data-permission-text=\"Title is private\" data-url=\"https://github.com/appsignal/appsignal-ruby/issues/1084\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/appsignal/appsignal-ruby/pull/1084/hovercard\" href=\"https://github.com/appsignal/appsignal-ruby/pull/1084\">#1084</a> from appsignal/bump-agent-0.35.10"}},{"before":"0012912685a4a98af9194dd2fb5e42b46464531f","after":"9dd041de07049155f51ea3c9d0d74e8b3e0c50f3","ref":"refs/heads/main","pushedAt":"2024-05-14T11:55:00.000Z","pushType":"pr_merge","commitsCount":2,"pusher":{"login":"unflxw","name":"Noemi","path":"/unflxw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45180344?s=80&v=4"},"commit":{"message":"Merge pull request #1083 from appsignal/fix-heartbeats-internal-logger\n\nDo not use `trace` on internal logger","shortMessageHtmlLink":"Merge pull request <a class=\"issue-link js-issue-link\" data-error-text=\"Failed to load title\" data-id=\"2295190367\" data-permission-text=\"Title is private\" data-url=\"https://github.com/appsignal/appsignal-ruby/issues/1083\" data-hovercard-type=\"pull_request\" data-hovercard-url=\"/appsignal/appsignal-ruby/pull/1083/hovercard\" href=\"https://github.com/appsignal/appsignal-ruby/pull/1083\">#1083</a> from appsignal/fix-heartbeats-internal-logger"}},{"before":null,"after":"ad5c99556421fe86501205465053466a91f28448","ref":"refs/heads/bump-agent-0.35.10","pushedAt":"2024-05-14T11:51:07.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"unflxw","name":"Noemi","path":"/unflxw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45180344?s=80&v=4"},"commit":{"message":"Bump agent to version 0.35.10\n\nThe agent update and changesets are updated automatically.\n\n[skip review]","shortMessageHtmlLink":"Bump agent to version 0.35.10"}},{"before":"4f85c115eabc55bcf76a241e4914fdb8e8fbf5a2","after":"30bb675ffa99ec1949a613f309e6c1792b88d4ce","ref":"refs/heads/fix-heartbeats-internal-logger","pushedAt":"2024-05-14T11:39:44.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"unflxw","name":"Noemi","path":"/unflxw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45180344?s=80&v=4"},"commit":{"message":"Do not use `trace` on internal logger\n\nThe internal logger does not support `trace`. Use `debug` instead.\n\nSince the heartbeat implementation intentionally swallows all errors\nand logs them, issues such as this would go unnoticed by the test\nsuite. Add assertions on the messages that are expected to be\nlogged to ensure that the implementation is actually working as\nexpected.","shortMessageHtmlLink":"Do not use <code>trace</code> on internal logger"}},{"before":"65e9ff991a163fd258d58b81599f9bc743128307","after":"4f85c115eabc55bcf76a241e4914fdb8e8fbf5a2","ref":"refs/heads/fix-heartbeats-internal-logger","pushedAt":"2024-05-14T11:36:58.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"unflxw","name":"Noemi","path":"/unflxw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45180344?s=80&v=4"},"commit":{"message":"Do not use `trace` on internal logger\n\nThe internal logger does not support `trace`. Use `debug` instead.\n\nSince the heartbeat implementation intentionally swallows all errors\nand logs them, issues such as this would go unnoticed by the test\nsuite. Add assertions on the messages that are expected to be\nlogged to ensure that the implementation is actually working as\nexpected.","shortMessageHtmlLink":"Do not use <code>trace</code> on internal logger"}},{"before":"efedc6b1a12e7e2d577e9fb8614ea94d40c7ebf6","after":"65e9ff991a163fd258d58b81599f9bc743128307","ref":"refs/heads/fix-heartbeats-internal-logger","pushedAt":"2024-05-14T11:34:36.000Z","pushType":"force_push","commitsCount":0,"pusher":{"login":"unflxw","name":"Noemi","path":"/unflxw","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/45180344?s=80&v=4"},"commit":{"message":"Do not use `trace` on internal logger\n\nThe internal logger does not support `trace`. Use `debug` instead.\n\nSince the heartbeat implementation intentionally swallows all errors\nand logs them, issues such as this would go unnoticed by the test\nsuite. Add assertions on the messages that are expected to be\nlogged to ensure that the implementation is actually working as\nexpected.","shortMessageHtmlLink":"Do not use <code>trace</code> on internal logger"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"djE6ks8AAAAEWs1UTAA","startCursor":null,"endCursor":null}},"title":"Activity · appsignal/appsignal-ruby"}