{"payload":{"feedbackUrl":"https://github.com/orgs/community/discussions/53140","repo":{"id":393533129,"defaultBranch":"master","name":"sonic-linkmgrd","ownerLogin":"sonic-net","currentUserCanPush":false,"isFork":false,"isEmpty":false,"createdAt":"2021-08-06T23:59:13.000Z","ownerAvatar":"https://avatars.githubusercontent.com/u/102750714?v=4","public":true,"private":false,"isOrgOwned":true},"refInfo":{"name":"","listCacheKey":"v0:1717539854.0","currentOid":""},"activityList":{"items":[{"before":"575423c1ffff7152fdaec8099977fae2f9c926e2","after":"d8acc760e1eb7a90b8eaee556337ccb75210771f","ref":"refs/heads/202311","pushedAt":"2024-08-28T18:34:08.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"yxieca","name":"Ying Xie","path":"/yxieca","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/18753401?s=80&v=4"},"commit":{"message":"[link prober] print out error code message when `sendHeartbeat` fails (#266) (#276)\n\nSummary:\r\nFixes # (issue)\r\nPrint out error code message when sendHeartbeat fails.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com\r\n\r\nCo-authored-by: Jing Zhang ","shortMessageHtmlLink":"[link prober] print out error code message when sendHeartbeat fails ("}},{"before":"7411fb35f51b5906cc7f462ac79809c2b6a5e1fc","after":"d1b5dcc3d2bebf3d918108bd68915a53f443221e","ref":"refs/heads/202305","pushedAt":"2024-08-28T14:42:10.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"StormLiangMS","name":null,"path":"/StormLiangMS","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/89824293?s=80&v=4"},"commit":{"message":"Fix default route race condition UT (#258) (#273)\n\nWhat is the motivation for this PR?\r\nCherry-pick #258 into 202305.\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com","shortMessageHtmlLink":"Fix default route race condition UT (#258) (#273)"}},{"before":"b068f0253bb9991905629650bc70f9110540c147","after":"7411fb35f51b5906cc7f462ac79809c2b6a5e1fc","ref":"refs/heads/202305","pushedAt":"2024-08-28T10:14:25.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"xumia","name":null,"path":"/xumia","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/59720581?s=80&v=4"},"commit":{"message":"Fix pipeline for 202305 swss common vstest failed. (#275)\n\nDescription of PR\r\nSummary:\r\nFixes # (issue)\r\nswss-common has vstest issues.\r\nDon't block linkmgrd by swss common vstest.\r\n\r\nType of change\r\nPipeline change\r\n\r\n Bug fix\r\n New feature\r\n Doc/Design\r\n Unit test\r\nApproach\r\nWhat is the motivation for this PR?\r\nWork item tracking\r\nMicrosoft ADO (number only): 29246135\r\nHow did you do it?\r\nHow did you verify/test it?\r\nAny platform specific information?\r\nDocumentation","shortMessageHtmlLink":"Fix pipeline for 202305 swss common vstest failed. (#275)"}},{"before":"ff0cc80a77092afb45efa638e18a3dc44e3d70dc","after":"575423c1ffff7152fdaec8099977fae2f9c926e2","ref":"refs/heads/202311","pushedAt":"2024-08-28T09:17:05.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"Fix state machine handler race conditions introduced by `strand::wrap` (#257)\n\nApproach\r\nWhat is the motivation for this PR?\r\nAs the subject.\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28585413\r\nHow did you do it?\r\nPost the handler directly to handler instead of calling it with strand::wrap\r\n\r\nHow did you verify/test it?\r\nUT\r\n\r\nAny platform specific information?\r\nDocumentation","shortMessageHtmlLink":"Fix state machine handler race conditions introduced by strand::wrap ("}},{"before":"2725e7c67688fb6dcf05c99a6be7bf18d69c3c40","after":"7d875172a13d7184249facf4142c640f009200b2","ref":"refs/heads/202405","pushedAt":"2024-08-24T00:07:23.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[link prober] print out error code message when `sendHeartbeat` fails (#266)\n\nSummary:\r\nFixes # (issue)\r\nPrint out error code message when sendHeartbeat fails.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com","shortMessageHtmlLink":"[link prober] print out error code message when sendHeartbeat fails ("}},{"before":"f7ef0fa5a293c343bb2506d550823c47d3bcec7d","after":"2725e7c67688fb6dcf05c99a6be7bf18d69c3c40","ref":"refs/heads/202405","pushedAt":"2024-08-24T00:07:19.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"Fix state machine handler race conditions introduced by `strand::wrap` (#257)\n\nApproach\r\nWhat is the motivation for this PR?\r\nAs the subject.\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28585413\r\nHow did you do it?\r\nPost the handler directly to handler instead of calling it with strand::wrap\r\n\r\nHow did you verify/test it?\r\nUT\r\n\r\nAny platform specific information?\r\nDocumentation","shortMessageHtmlLink":"Fix state machine handler race conditions introduced by strand::wrap ("}},{"before":"d25788cc2a94a614608ae2c09be21766bb1f91df","after":"f7ef0fa5a293c343bb2506d550823c47d3bcec7d","ref":"refs/heads/202405","pushedAt":"2024-08-23T11:06:39.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] Fix the oscillation logic (#261)\n\nApproach\r\nWhat is the motivation for this PR?\r\nFix the unexpected toggle introduced by the oscillation logic.\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28397786\r\nHow did you do it?\r\nThe oscillation is introduced to allow the active side to toggle to standby if no heartbeat is received.\r\nThe workflow is described as the following:\r\n\r\n(wait, active, up) ---> set oscillation timer [1]\r\n...\r\n(wait, active, up) ---> (wait, wait, up) [2]\r\n(wait, wait, up) ---> (wait, active, up)\r\n...\r\n(wait, active, up) <--- oscillation timer expires, toggle to standby [3]\r\n[1]: the ToR enters (wait, active, up), no heartbeats received, oscillation timer is set.\r\n[2]: the ToR consistently probes the mux status, and transits between (wait, active, up) and (wait, wait, up).\r\n[3]: when the oscillation timer expires and the ToR is (wait, active, up), make the toggle to standby request.\r\n\r\nWe need to ensure that, the ToR is only allowed to transits between (wait, active, up) and (wait, wait, up) during [2]. So any link prober active/standby, mux standby, or link down events should cancel the oscillation.\r\n\r\nHow did you verify/test it?\r\nUT\r\n\r\nAny platform specific information?\r\nDocumentation","shortMessageHtmlLink":"[active-standby] Fix the oscillation logic (#261)"}},{"before":"8427a890714d03d7252e7c5f78cc67052e3fcb36","after":"ff0cc80a77092afb45efa638e18a3dc44e3d70dc","ref":"refs/heads/202311","pushedAt":"2024-08-23T11:06:34.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] Fix the oscillation logic (#261)\n\nApproach\r\nWhat is the motivation for this PR?\r\nFix the unexpected toggle introduced by the oscillation logic.\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28397786\r\nHow did you do it?\r\nThe oscillation is introduced to allow the active side to toggle to standby if no heartbeat is received.\r\nThe workflow is described as the following:\r\n\r\n(wait, active, up) ---> set oscillation timer [1]\r\n...\r\n(wait, active, up) ---> (wait, wait, up) [2]\r\n(wait, wait, up) ---> (wait, active, up)\r\n...\r\n(wait, active, up) <--- oscillation timer expires, toggle to standby [3]\r\n[1]: the ToR enters (wait, active, up), no heartbeats received, oscillation timer is set.\r\n[2]: the ToR consistently probes the mux status, and transits between (wait, active, up) and (wait, wait, up).\r\n[3]: when the oscillation timer expires and the ToR is (wait, active, up), make the toggle to standby request.\r\n\r\nWe need to ensure that, the ToR is only allowed to transits between (wait, active, up) and (wait, wait, up) during [2]. So any link prober active/standby, mux standby, or link down events should cancel the oscillation.\r\n\r\nHow did you verify/test it?\r\nUT\r\n\r\nAny platform specific information?\r\nDocumentation","shortMessageHtmlLink":"[active-standby] Fix the oscillation logic (#261)"}},{"before":"26dbdc746cdf15e7e9d6e34671a5736278586064","after":"d25788cc2a94a614608ae2c09be21766bb1f91df","ref":"refs/heads/202405","pushedAt":"2024-08-23T10:13:13.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lolyu","name":"Longxiang Lyu","path":"/lolyu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35479537?s=80&v=4"},"commit":{"message":"Fix default route race condition UT (#258) (#268)\n\nApproach\r\nWhat is the motivation for this PR?\r\nFix the UT failure introduced by #254.\r\nThe failure is due to that, the wait time for the two default route handlers to finish is 10ms, which is not sufficient on some build image agents which has limited CPU resource.\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28471183\r\nHow did you do it?\r\nLet's increase the wait time to 8s.\r\n\r\nHow did you verify/test it?\r\nUT passed.\r\n\r\nAny platform specific information?\r\nDocumentation","shortMessageHtmlLink":"Fix default route race condition UT (#258) (#268)"}},{"before":"5730b79835c658851a0b223d397ee28e5441f8f7","after":"26dbdc746cdf15e7e9d6e34671a5736278586064","ref":"refs/heads/202405","pushedAt":"2024-08-21T17:21:52.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] Fix default route handler race condition (#254)\n\nWhat is the motivation for this PR?\r\nFix the race condition of the default route notification.\r\n\r\nThis is similar to #104\r\n\r\nIf there are multiple default route notifications received by linkmgrd, the mux port posts the default route handlers wrapped by strand. But boost asio doesn't guarantee the execution order of the default route handlers, so the final state machine default route could be any intermediate default route state.\r\n\r\nFor example, for default route notifications like:\r\n\r\n[2024-06-20 08:28:57.872911] [warning] MuxPort.cpp:365 handleDefaultRouteState: port: EtherTest01, state db default route state: na\r\n[2024-06-20 08:28:57.872954] [warning] MuxPort.cpp:365 handleDefaultRouteState: port: EtherTest01, state db default route state: ok\r\nThe final state machine default route state could be \"ok\" if the handler for \"ok\" is executed after the handler for \"na\".\r\nThe final state machine default route state could be \"na\" if the handler for \"ok\" is executed before the handler for \"na\".\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28471183\r\nHow did you do it?\r\npost the default route handlers directly through strand instead of using strand::wrap, so the handlers are executed in the same order as the handlers' post order.\r\n\r\nHow did you verify/test it?\r\nwithout this PR, UT fail:\r\n\r\nSigned-off-by: Longxiang Lyu ","shortMessageHtmlLink":"[active-standby] Fix default route handler race condition (#254)"}},{"before":"22f55a78c819a4bcd58fb53bfd8f865131e63df9","after":"287dbd70298c1743668182913644d2bbe3cdcd5b","ref":"refs/heads/master","pushedAt":"2024-08-13T17:32:21.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"zjswhhh","name":"Jing Zhang","path":"/zjswhhh","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26625909?s=80&v=4"},"commit":{"message":"[link prober] print out error code message when `sendHeartbeat` fails (#266)\n\nSummary:\r\nFixes # (issue)\r\nPrint out error code message when sendHeartbeat fails.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com","shortMessageHtmlLink":"[link prober] print out error code message when sendHeartbeat fails ("}},{"before":"6fcab47406502cd41d60267b36dc362555487d7c","after":"22f55a78c819a4bcd58fb53bfd8f865131e63df9","ref":"refs/heads/master","pushedAt":"2024-08-06T11:43:11.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lolyu","name":"Longxiang Lyu","path":"/lolyu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35479537?s=80&v=4"},"commit":{"message":"Fix state machine handler race conditions introduced by `strand::wrap` (#257)\n\nApproach\r\nWhat is the motivation for this PR?\r\nAs the subject.\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28585413\r\nHow did you do it?\r\nPost the handler directly to handler instead of calling it with strand::wrap\r\n\r\nHow did you verify/test it?\r\nUT\r\n\r\nAny platform specific information?\r\nDocumentation","shortMessageHtmlLink":"Fix state machine handler race conditions introduced by strand::wrap ("}},{"before":"7706c2c476076dc7f6f35e3d8a7957295658a53d","after":"b068f0253bb9991905629650bc70f9110540c147","ref":"refs/heads/202305","pushedAt":"2024-08-06T09:16:24.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] Fix default route handler race condition (#254)\n\nWhat is the motivation for this PR?\r\nFix the race condition of the default route notification.\r\n\r\nThis is similar to #104\r\n\r\nIf there are multiple default route notifications received by linkmgrd, the mux port posts the default route handlers wrapped by strand. But boost asio doesn't guarantee the execution order of the default route handlers, so the final state machine default route could be any intermediate default route state.\r\n\r\nFor example, for default route notifications like:\r\n\r\n[2024-06-20 08:28:57.872911] [warning] MuxPort.cpp:365 handleDefaultRouteState: port: EtherTest01, state db default route state: na\r\n[2024-06-20 08:28:57.872954] [warning] MuxPort.cpp:365 handleDefaultRouteState: port: EtherTest01, state db default route state: ok\r\nThe final state machine default route state could be \"ok\" if the handler for \"ok\" is executed after the handler for \"na\".\r\nThe final state machine default route state could be \"na\" if the handler for \"ok\" is executed before the handler for \"na\".\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28471183\r\nHow did you do it?\r\npost the default route handlers directly through strand instead of using strand::wrap, so the handlers are executed in the same order as the handlers' post order.\r\n\r\nHow did you verify/test it?\r\nwithout this PR, UT fail:\r\n\r\nSigned-off-by: Longxiang Lyu ","shortMessageHtmlLink":"[active-standby] Fix default route handler race condition (#254)"}},{"before":"5c416c305d82797ef20ef454f30eef33d482a749","after":"8427a890714d03d7252e7c5f78cc67052e3fcb36","ref":"refs/heads/202311","pushedAt":"2024-07-24T05:01:51.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":" [active-standby] raising log level to notice for timed oscillation config change (#262)\n\nSummary:\r\nFixes # (issue)\r\n\r\nRaising log level to notice for timed oscillation config change.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com\r\n\r\nMicrosoft ADO (number only):\r\n28557265","shortMessageHtmlLink":" [active-standby] raising log level to notice for timed oscillation c…"}},{"before":"f96d40cfbe4a771c60579935998ae2c52816c4ea","after":"5730b79835c658851a0b223d397ee28e5441f8f7","ref":"refs/heads/202405","pushedAt":"2024-07-24T05:01:47.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":" [active-standby] raising log level to notice for timed oscillation config change (#262)\n\nSummary:\r\nFixes # (issue)\r\n\r\nRaising log level to notice for timed oscillation config change.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com\r\n\r\nMicrosoft ADO (number only):\r\n28557265","shortMessageHtmlLink":" [active-standby] raising log level to notice for timed oscillation c…"}},{"before":"2b7e4f975ff0f2a5d6cd77282e74490928db8000","after":"6fcab47406502cd41d60267b36dc362555487d7c","ref":"refs/heads/master","pushedAt":"2024-07-11T22:59:00.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"zjswhhh","name":"Jing Zhang","path":"/zjswhhh","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26625909?s=80&v=4"},"commit":{"message":" [active-standby] raising log level to notice for timed oscillation config change (#262)\n\nSummary:\r\nFixes # (issue)\r\n\r\nRaising log level to notice for timed oscillation config change.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com\r\n\r\nMicrosoft ADO (number only):\r\n28557265","shortMessageHtmlLink":" [active-standby] raising log level to notice for timed oscillation c…"}},{"before":"9768268cf11cdfab1eccb194c0ce762e372aa536","after":"2b7e4f975ff0f2a5d6cd77282e74490928db8000","ref":"refs/heads/master","pushedAt":"2024-07-02T04:36:20.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lolyu","name":"Longxiang Lyu","path":"/lolyu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35479537?s=80&v=4"},"commit":{"message":"[active-standby] Fix the oscillation logic (#261)\n\nApproach\r\nWhat is the motivation for this PR?\r\nFix the unexpected toggle introduced by the oscillation logic.\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28397786\r\nHow did you do it?\r\nThe oscillation is introduced to allow the active side to toggle to standby if no heartbeat is received.\r\nThe workflow is described as the following:\r\n\r\n(wait, active, up) ---> set oscillation timer [1]\r\n...\r\n(wait, active, up) ---> (wait, wait, up) [2]\r\n(wait, wait, up) ---> (wait, active, up)\r\n...\r\n(wait, active, up) <--- oscillation timer expires, toggle to standby [3]\r\n[1]: the ToR enters (wait, active, up), no heartbeats received, oscillation timer is set.\r\n[2]: the ToR consistently probes the mux status, and transits between (wait, active, up) and (wait, wait, up).\r\n[3]: when the oscillation timer expires and the ToR is (wait, active, up), make the toggle to standby request.\r\n\r\nWe need to ensure that, the ToR is only allowed to transits between (wait, active, up) and (wait, wait, up) during [2]. So any link prober active/standby, mux standby, or link down events should cancel the oscillation.\r\n\r\nHow did you verify/test it?\r\nUT\r\n\r\nAny platform specific information?\r\nDocumentation","shortMessageHtmlLink":"[active-standby] Fix the oscillation logic (#261)"}},{"before":"bf9698411cce6ea8676dcd1365032e79411c68ed","after":"5c416c305d82797ef20ef454f30eef33d482a749","ref":"refs/heads/202311","pushedAt":"2024-06-26T05:01:52.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"Fix default route race condition UT (#258)\n\nSigned-off-by: Longxiang Lyu ","shortMessageHtmlLink":"Fix default route race condition UT (#258)"}},{"before":"d0124f5254395ca1dc4aa0853769ac8efdbf380d","after":"9768268cf11cdfab1eccb194c0ce762e372aa536","ref":"refs/heads/master","pushedAt":"2024-06-26T05:01:19.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"yxieca","name":"Ying Xie","path":"/yxieca","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/18753401?s=80&v=4"},"commit":{"message":"Fix default route race condition UT (#258)\n\nSigned-off-by: Longxiang Lyu ","shortMessageHtmlLink":"Fix default route race condition UT (#258)"}},{"before":"ad392988af81609fe432eb285641bb51516f2958","after":"bf9698411cce6ea8676dcd1365032e79411c68ed","ref":"refs/heads/202311","pushedAt":"2024-06-21T20:01:36.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] Fix default route handler race condition (#254)\n\nWhat is the motivation for this PR?\r\nFix the race condition of the default route notification.\r\n\r\nThis is similar to #104\r\n\r\nIf there are multiple default route notifications received by linkmgrd, the mux port posts the default route handlers wrapped by strand. But boost asio doesn't guarantee the execution order of the default route handlers, so the final state machine default route could be any intermediate default route state.\r\n\r\nFor example, for default route notifications like:\r\n\r\n[2024-06-20 08:28:57.872911] [warning] MuxPort.cpp:365 handleDefaultRouteState: port: EtherTest01, state db default route state: na\r\n[2024-06-20 08:28:57.872954] [warning] MuxPort.cpp:365 handleDefaultRouteState: port: EtherTest01, state db default route state: ok\r\nThe final state machine default route state could be \"ok\" if the handler for \"ok\" is executed after the handler for \"na\".\r\nThe final state machine default route state could be \"na\" if the handler for \"ok\" is executed before the handler for \"na\".\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28471183\r\nHow did you do it?\r\npost the default route handlers directly through strand instead of using strand::wrap, so the handlers are executed in the same order as the handlers' post order.\r\n\r\nHow did you verify/test it?\r\nwithout this PR, UT fail:\r\n\r\nSigned-off-by: Longxiang Lyu ","shortMessageHtmlLink":"[active-standby] Fix default route handler race condition (#254)"}},{"before":"f96d40cfbe4a771c60579935998ae2c52816c4ea","after":"d0124f5254395ca1dc4aa0853769ac8efdbf380d","ref":"refs/heads/master","pushedAt":"2024-06-21T17:34:39.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"yxieca","name":"Ying Xie","path":"/yxieca","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/18753401?s=80&v=4"},"commit":{"message":"[active-standby] Fix default route handler race condition (#254)\n\nWhat is the motivation for this PR?\r\nFix the race condition of the default route notification.\r\n\r\nThis is similar to #104\r\n\r\nIf there are multiple default route notifications received by linkmgrd, the mux port posts the default route handlers wrapped by strand. But boost asio doesn't guarantee the execution order of the default route handlers, so the final state machine default route could be any intermediate default route state.\r\n\r\nFor example, for default route notifications like:\r\n\r\n[2024-06-20 08:28:57.872911] [warning] MuxPort.cpp:365 handleDefaultRouteState: port: EtherTest01, state db default route state: na\r\n[2024-06-20 08:28:57.872954] [warning] MuxPort.cpp:365 handleDefaultRouteState: port: EtherTest01, state db default route state: ok\r\nThe final state machine default route state could be \"ok\" if the handler for \"ok\" is executed after the handler for \"na\".\r\nThe final state machine default route state could be \"na\" if the handler for \"ok\" is executed before the handler for \"na\".\r\n\r\nSigned-off-by: Longxiang Lyu lolv@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only): 28471183\r\nHow did you do it?\r\npost the default route handlers directly through strand instead of using strand::wrap, so the handlers are executed in the same order as the handlers' post order.\r\n\r\nHow did you verify/test it?\r\nwithout this PR, UT fail:\r\n\r\nSigned-off-by: Longxiang Lyu ","shortMessageHtmlLink":"[active-standby] Fix default route handler race condition (#254)"}},{"before":"746543176654fd6c55a4d94147c832d86317b86a","after":"ad392988af81609fe432eb285641bb51516f2958","ref":"refs/heads/202311","pushedAt":"2024-06-05T17:01:29.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] add knob to enable/disable oscillation (#250)\n\n### Approach\r\n#### What is the motivation for this PR?\r\nTo avoid test flakiness. \r\n \r\n##### Work item tracking\r\n- Microsoft ADO **(number only)**:\r\n- 28187403\r\n\r\n#### How did you do it?\r\n1. Add DB interface to enable/disable the oscillation feature\r\n2. Add DB interface to config the oscillation interval \r\n\r\n#### How did you verify/test it?\r\nTested on lab device: \r\n1. Knob was default on \r\n2. Turned it off\r\n3. Turned it on\r\n4. Changed the interval \r\n\r\n#### Any platform specific information?","shortMessageHtmlLink":"[active-standby] add knob to enable/disable oscillation (#250)"}},{"before":null,"after":"f96d40cfbe4a771c60579935998ae2c52816c4ea","ref":"refs/heads/202405","pushedAt":"2024-06-04T22:24:14.000Z","pushType":"branch_creation","commitsCount":0,"pusher":{"login":"yxieca","name":"Ying Xie","path":"/yxieca","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/18753401?s=80&v=4"},"commit":{"message":"[active-standby] add knob to enable/disable oscillation (#250)\n\n### Approach\r\n#### What is the motivation for this PR?\r\nTo avoid test flakiness. \r\n \r\n##### Work item tracking\r\n- Microsoft ADO **(number only)**:\r\n- 28187403\r\n\r\n#### How did you do it?\r\n1. Add DB interface to enable/disable the oscillation feature\r\n2. Add DB interface to config the oscillation interval \r\n\r\n#### How did you verify/test it?\r\nTested on lab device: \r\n1. Knob was default on \r\n2. Turned it off\r\n3. Turned it on\r\n4. Changed the interval \r\n\r\n#### Any platform specific information?","shortMessageHtmlLink":"[active-standby] add knob to enable/disable oscillation (#250)"}},{"before":"dd618447e2cc1838431d94f1f8bffa807ef65d89","after":"f96d40cfbe4a771c60579935998ae2c52816c4ea","ref":"refs/heads/master","pushedAt":"2024-05-25T09:48:14.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"lolyu","name":"Longxiang Lyu","path":"/lolyu","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/35479537?s=80&v=4"},"commit":{"message":"[active-standby] add knob to enable/disable oscillation (#250)\n\n### Approach\r\n#### What is the motivation for this PR?\r\nTo avoid test flakiness. \r\n \r\n##### Work item tracking\r\n- Microsoft ADO **(number only)**:\r\n- 28187403\r\n\r\n#### How did you do it?\r\n1. Add DB interface to enable/disable the oscillation feature\r\n2. Add DB interface to config the oscillation interval \r\n\r\n#### How did you verify/test it?\r\nTested on lab device: \r\n1. Knob was default on \r\n2. Turned it off\r\n3. Turned it on\r\n4. Changed the interval \r\n\r\n#### Any platform specific information?","shortMessageHtmlLink":"[active-standby] add knob to enable/disable oscillation (#250)"}},{"before":"f5e9b54b147e9cf24de1ed03f59170a5c20bf556","after":"7706c2c476076dc7f6f35e3d8a7957295658a53d","ref":"refs/heads/202305","pushedAt":"2024-04-05T17:01:23.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] reset mux probing backoff factor in link flaps (#245)\n\nDescription of PR\r\nSummary:\r\nFixes # (issue)\r\n\r\nThis PR is to address consistency in PXE boot scenario. In PXE boot, there is no ICMP heartbeats. During booting up, standby might switch to active. Mux probing is now the only way to find out mux toggles. But it's also expected to see mux probing fail when link is down, backoff factor can already be maximum when link is up.\r\n\r\nIf we don't reset backoff factor, it might take ~40s for peer to correct the inconsistency.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com","shortMessageHtmlLink":"[active-standby] reset mux probing backoff factor in link flaps (#245)"}},{"before":"27aed4037295b4c047c99047303c45a107888f1f","after":"746543176654fd6c55a4d94147c832d86317b86a","ref":"refs/heads/202311","pushedAt":"2024-03-22T05:01:29.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"draft (#231)","shortMessageHtmlLink":"draft (#231)"}},{"before":"1f5fcfd21b112c4765d20691c8c4bf8d2842f0c2","after":"27aed4037295b4c047c99047303c45a107888f1f","ref":"refs/heads/202311","pushedAt":"2024-03-21T23:02:25.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] reset mux probing backoff factor in link flaps (#245)\n\nDescription of PR\r\nSummary:\r\nFixes # (issue)\r\n\r\nThis PR is to address consistency in PXE boot scenario. In PXE boot, there is no ICMP heartbeats. During booting up, standby might switch to active. Mux probing is now the only way to find out mux toggles. But it's also expected to see mux probing fail when link is down, backoff factor can already be maximum when link is up.\r\n\r\nIf we don't reset backoff factor, it might take ~40s for peer to correct the inconsistency.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com","shortMessageHtmlLink":"[active-standby] reset mux probing backoff factor in link flaps (#245)"}},{"before":"74c33eacf4325b6e0f3e3b11fc6c50b4222921a1","after":"dd618447e2cc1838431d94f1f8bffa807ef65d89","ref":"refs/heads/master","pushedAt":"2024-03-14T22:04:46.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"zjswhhh","name":"Jing Zhang","path":"/zjswhhh","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/26625909?s=80&v=4"},"commit":{"message":"[active-standby] reset mux probing backoff factor in link flaps (#245)\n\nDescription of PR\r\nSummary:\r\nFixes # (issue)\r\n\r\nThis PR is to address consistency in PXE boot scenario. In PXE boot, there is no ICMP heartbeats. During booting up, standby might switch to active. Mux probing is now the only way to find out mux toggles. But it's also expected to see mux probing fail when link is down, backoff factor can already be maximum when link is up.\r\n\r\nIf we don't reset backoff factor, it might take ~40s for peer to correct the inconsistency.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com","shortMessageHtmlLink":"[active-standby] reset mux probing backoff factor in link flaps (#245)"}},{"before":"70b6d15fad7f40d80597791cbc963a59d68c087f","after":"1f5fcfd21b112c4765d20691c8c4bf8d2842f0c2","ref":"refs/heads/202311","pushedAt":"2024-03-04T06:06:22.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"Exclude DbInterface in PR coverage check (#224)\n\nSummary:\r\nFixes # (issue)\r\nLinkmgrd unit tests overrides DbInterface functions with fake handlers and verified the invoking counters instead of interacting with real Redis Dbs.\r\n\r\nHence, excluding Dbinterface.cpp from coverage checker.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com","shortMessageHtmlLink":"Exclude DbInterface in PR coverage check (#224)"}},{"before":"74e455e01779e7da240c50d97d40de550fc2aa72","after":"70b6d15fad7f40d80597791cbc963a59d68c087f","ref":"refs/heads/202311","pushedAt":"2024-02-02T05:04:13.000Z","pushType":"pr_merge","commitsCount":1,"pusher":{"login":"mssonicbld","name":null,"path":"/mssonicbld","primaryAvatarUrl":"https://avatars.githubusercontent.com/u/79238446?s=80&v=4"},"commit":{"message":"[active-standby] Fix `show mux status` inconsistency introduced by orchagent rollback (#225)\n\nApproach\r\nWhat is the motivation for this PR?\r\nThis is to fix the show mux status inconsistency introduced by orchagent roll back.\r\n\r\nIn mux port state machine design, linkmgrd honors hardware state for active-standby ports, and never intends to trigger a secondary toggle when everything is healthy. But after we introduce orchagent rollback, show mux status can return unmatched APP_DB and STATE_DB entries for this, which blocks upgrade.\r\n\r\nHence, submitting this PR as a workaround.\r\n\r\nsign-off: Jing Zhang zhangjing@microsoft.com\r\n\r\nWork item tracking\r\nMicrosoft ADO (number only):\r\n26136887\r\n\r\nHow did you do it?\r\nHow did you verify/test it?","shortMessageHtmlLink":"[active-standby] Fix show mux status inconsistency introduced by or…"}}],"hasNextPage":true,"hasPreviousPage":false,"activityType":"all","actor":null,"timePeriod":"all","sort":"DESC","perPage":30,"cursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOC0yOFQxODozNDowOC4wMDAwMDBazwAAAASm1nwE","startCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wOC0yOFQxODozNDowOC4wMDAwMDBazwAAAASm1nwE","endCursor":"Y3Vyc29yOnYyOpK7MjAyNC0wMi0wMlQwNTowNDoxMy4wMDAwMDBazwAAAAPv1_i9"}},"title":"Activity · sonic-net/sonic-linkmgrd"}