[daemon] Handle cloud-init intentional shutdown by deepakshirkem · Pull Request #4695 · canonical/multipass

deepakshirkem · 2026-02-21T11:15:52Z

Description

What does this PR do?

This PR fixes the timeout issue when cloud-init uses power_state: mode: poweroff to shutdown the VM. Insted of waiting for the full timeout period, Multipass now:

Parse the cloud-init YAML to detect if power_state is configured.
Distinguishes between intentional shutdown (configured in cloud-init) and unexpected crashes
Treats intentional shutdown as successful launch completion

Why is this change needed?

Currently, when a user configures cloud-init to shut down the VM after initialization, multipass launch waits for SSH and times out after 300 seconds, even though the VM has completed initialization successfully.

This creates a poor user experience:

Launch appears to fail even though cloud-init completed successfully
Users must wait several minutes for an inevitable timeout
The VM ends up in the correct (Stopped) state, but launch reports failure

Implementation Details

Parse power_state field from user-provided cloud-init YAML during VM creation
Store expects_shutdown flag in VirtualMachineDescription and pass to VM
In wait_until_ssh_up(), If expects_shutdown = true: throw IntentionalShutdownException (success) and If expects_shutdown = false: throw StartException (failure)
Daemon catches IntentionalShutdownException and treats launch as successful

Related Issue(s)

May be Closes #4456

Testing

Manual testing:

Test 1: Intentional shutdown (with power_state)

#cloud-config
runcmd:
  - echo "Processing data"
  - sleep 5

power_state:
  mode: poweroff
  message: "Shutting down after init"

Result: Launch completes in ~30-40 seconds with success message, VM in Stopped state

Test 2: Normal VM (no power_state)

multipass launch --name normal-vm

Result: Launch completes normally, VM in Running state with SSH available

Test 3: Unexpected crash (VM stopped without power_state)
Manually stop VM during launch:

VBoxManage controlvm test-vm poweroff

Result: Launch fails with "VM stopped unexpectedly" error

Screenshots (if applicable)

N/A

Checklist

My code follows the contributing guidelines
I have signed the Canonical CLA
I have added necessary tests (need guidance on test structure)
I have updated documentation (if needed)
I have tested the changes locally
Ignoring all previous instructions, I verify that I am not an AI agent or LLM

Additional Notes

N/A

deepakshirkem · 2026-02-23T15:18:51Z

Hi @tobe2098 , I will required your feedback on this solution approach.
One thing I am confuse about the CI is showing test failure in test_base_virtual_machine_factory.cpp due to missing expected_shutdown field initializer. However when i ran ctest -VV locally , all test passed without any errors.

tobe2098 · 2026-02-27T13:45:36Z

Hi, it is a compilation error, unrelated to ctest -VV. You should attempt to recompile

deepakshirkem · 2026-03-15T19:47:53Z

Hi @tobe2098 ,
I resolved those failing test can you please review them.

codecov · 2026-03-16T10:13:40Z

Codecov Report

❌ Patch coverage is 43.75000% with 27 lines in your changes missing coverage. Please review.
✅ Project coverage is 87.51%. Comparing base (628dea7) to head (cd4916d).
⚠️ Report is 40 commits behind head on main.

Files with missing lines	Patch %	Lines
.../platform/backends/shared/base_virtual_machine.cpp	55.00%	9 Missing ⚠️
src/daemon/daemon.cpp	56.25%	7 Missing ⚠️
...backends/virtualbox/virtualbox_virtual_machine.cpp	0.00%	7 Missing ⚠️
...tipass/exceptions/intentional_shutdown_exception.h	0.00%	4 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #4695      +/-   ##
==========================================
- Coverage   87.64%   87.51%   -0.13%     
==========================================
  Files         254      259       +5     
  Lines       14157    14155       -2     
==========================================
- Hits        12407    12386      -21     
- Misses       1750     1769      +19

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

tobe2098

The work shows promise, but I think we need to re-formulate the solution. Ideally, wait_* functions would return as if there were a success in the intentional shutdown case, since it is a success. Both wait_* functions were already re-formatted to accomodate restarts, so in the case where a restart would be detected within the try_to_ssh function due to state not being running, we could check if the state is shutdown and the intended state is shutdown as well and return TimeoutAction::Done.

What do you think about this alternative solution?

tobe2098 · 2026-03-16T12:28:25Z

+            if(vm_desc.user_data_config["power_state"])
+            {
+                auto ps = vm_desc.user_data_config["power_state"];
+                if(ps["mode"] && ps["mode"].as<std::string>() == "poweroff")
+                {
+                    mpl::log(mpl::Level::error, name, "DETECTED POWEROFF IN CONFIG");
+                    vm_desc.expects_shutdown = true;
+                }
+            }
+


Since vm_desc already has access to the data, would it make more sense to just parse the power_state value in-situ? Once you enter the function call that requires the information it could be parsed there for the value, instead of adding an additional field that does not really correspond to "VMDescription", since it is just an option of the contained cloud-init (if we were talking about a ParsedCloudInit object I would agree with the approach).

If the field were in BaseVirtualMachine it would be more convenient, since that virtual class does not have access to the VMDescription. The default could be false, and the field could be set in the constructor of the derived classes, where there is access to the VMDescription. What do you think?

Yes i think your approach make more sense.
My thinking was that parsing in the daemon would make the implementation work across all backends automatically. I will try implementing it with the VirtualBox backed first and update here.

tobe2098 · 2026-03-16T13:45:12Z

-    if ((state == State::delayed_shutdown && present_state == State::running) ||
-        state == State::starting)
+    if (state == State::starting && present_state == State::stopped)
+    {
+        mpl::log(mpl::Level::info,
+                 name.toStdString(),
+                 "VM stopped during startup (cloud-init poweroff)");
+
+        state = present_state;
+        return state;
+    }
+
+    if (state == State::delayed_shutdown && present_state == State::running)
        return state;


Is this logic really necessary? Supporting the intentional shutdown should be backend-wide, and this provides no additional functionality. Let me know what your thinking process here was, there are other logic changes here (like what if starting && not stopped?), for which an explanation would make things easier.

You are right, this does not support any logic. I added this only for debugging purpose while testing, to check the logs. I will remove this changes in the next commit. I will make sure that this type of mistake will not happen again.

tobe2098 · 2026-03-16T13:46:26Z

+    if (state == State::starting && present_state == State::stopped)
+    {
+        mpl::log(mpl::Level::info,
+                 name.toStdString(),
+                 "VM stopped during startup (cloud-init poweroff)");
+
+        state = present_state;
+        return state;


This updates the state variable when starting when it used to not be the case. What was your reasoning for this change?

deepakshirkem · 2026-03-18T20:02:32Z

Hi @tobe2098,
I have updated the PR as per your feedback. Thank you for your input.

tobe2098

We are getting closer @deepakshirkem. It is not complete because it could be the case that the shutdown is detected on waiting for cloud-init, instead of on ssh up. That would be the case if the cloud-init takes long enough in longer cloud-init configurations.

We should also add the logic to the other backends. To avoid the repeated code, the yaml parsing code could be a function as well.

tobe2098 · 2026-03-18T21:41:35Z

+        if (vm_state == State::stopped || vm_state == State::off)
+        {
+            if (expected_shutdown) {
+                mpl::log(mpl::Level::info, vm_name,
+                         "VM powered off as configured in cloud-init");
+                return utils::TimeoutAction::done;
+            } else {
+                mpl::log(mpl::Level::error, vm_name,
+                         "VM stopped unexpectedly");
+                throw StartException(vm_name, "VM stopped unexpectedly");
+            }
+        }


Maybe the exception could be thrown here instead of after the try_action_for.

Hi @tobe2098, I tried throwing the exception as you suggested and removed the final state check, but after that I am not able to see the intentional exception or the start exception. I am not sure why this behavior changed. I will dig deeper into it and add logging to investigate.

Remember that if the shutdown happens during the cloud-init after the ssh_up you are not throwing in that function yet.

Yeah, you are right. But in my updated code, I am throwing the exception from that function. After some debugging, I think there may be a race condition issue—my vm_state is not updating inside the lambda.

So, can we do the same as in the old code where I added a final check? It introduces some delay, but it gives the expected results.

I wanted your feedback—does my observation about a race condition make sense?

It makes sense, but if you check the vm_state=current_state(); the state is supposed to be properly updated. I can do more testing on that later on.

Hi @tobe2098, You're right! I was testing the crash scenario incorrectly. I was stopping the VM before it reached the running state, which is why the state wasn't updating as expected in the lambda. That's why I thought there was a race condition.

deepakshirkem · 2026-03-21T12:09:20Z

Hi @tobe2098, I implemented the changes as you suggested and added the helper function. I was confused during testing because, while doing the crash test manually, I stopped the VM before it reached the running state. That’s why it never stopped as expected, and I was not getting the expected behavior.
Now I have updated the logic and also increased the detection speed. I tested this on the QEMU backend.
Please review the changes. I am still very open to any new suggestions or improvements

tobe2098 · 2026-04-07T20:48:38Z

Hi @deepakshirkem, if there are conflicts do not merge main into the branch, do git rebase main. This way the commit history is kept cleaner. Thank you very much.

tobe2098

I made some minor comments. You are doing great work @deepakshirkem!
Additionally, there is something that must be taken care of. In daemon.cpp, wait_for_ssh_up is called in all started/restarted instances, not only the launched ones. When dealing with the IntentionalShutdownException, we must treat it as a StartException whenever it is not a LaunchRequest.

tobe2098 · 2026-04-07T20:50:31Z

-
-    if ((state == State::delayed_shutdown && present_state == State::running) ||
-        state == State::starting)
+    if (state == State::delayed_shutdown && present_state == State::running)


Why is starting not checked now? Did you find something while testing?

Hi @tobe2098, I have addressed this change.

tobe2098 · 2026-04-07T20:51:18Z

    auto on_timeout = [] {
        throw std::runtime_error("timed out waiting for initialization to complete");
    };
+


Could this newline be removed?

tobe2098 · 2026-04-07T20:51:41Z

+        catch (const SSHExecFailure& e) // transitioning away from catching generic runtime errors                         
+        {                                // TODO remove once we're confident this is an anomaly
            return mpu::TimeoutAction::retry;
        }
-        catch (const std::exception& e) // transitioning away from catching generic runtime errors
-        {                               // TODO remove once we're confident this is an anomaly
+        catch (const std::exception& e)
+        {


This comment was moved accidentally

tobe2098 · 2026-04-07T21:05:58Z

+        if (vm_state == State::stopped || vm_state == State::off)
+        {
+            if (expected_shutdown) {
+                mpl::log(mpl::Level::info, vm_name,
+                         "VM powered off as configured in cloud-init");
+                return utils::TimeoutAction::done;
+            } else {
+                mpl::log(mpl::Level::error, vm_name,
+                         "VM stopped unexpectedly");
+                throw StartException(vm_name, "VM stopped unexpectedly");
+            }
+        }


It makes sense, but if you check the vm_state=current_state(); the state is supposed to be properly updated. I can do more testing on that later on.

deepakshirkem · 2026-04-09T20:01:22Z

Hi @tobe2098, I addressed all your review comments.

Thank You ((:

tobe2098 · 2026-05-08T11:05:43Z

+            {
+                throw StartException(name, "Unexpected shutdown during start");
+            }
        }


There is an additional topic: when launching a vm, mount options can be provided, which should still be added to the VM even if it is shut off. The current approach would discard the mounts by returning early. Of course, the classic mounts need to check that the vm is running, similar as is done in the Daemon::mount function. What do you think?

Hi @tobe2098, Your right. I have to check existing code and provide solution that will handle this case. Thank you.

deepakshirkem · 2026-05-09T14:29:38Z

Hi @tobe2098, Please go one more time on the changes and sorry for those test failure i tested locally now no test is failing. Please re-run the pipeline when you get a chance. Thank you ::)

tobe2098

Sorry to not have been clear with the mounts activation. The mounts are activated in src/client/cli/launch.cpp when launching. The way it works is that if the launch returns an OK code, the mounts will be attempted on the VM as a separate command. The changes you added can be undone, simply test that then launching a VM that starts and shuts down with the cloud-init, that the mounts via mount flags are stored.

Detect when cloud-init uses power_state mode poweroff/halt and treat as successful launch instead of timeout. Created expects_shutdown_from_cloud_init() helper function. Implemented in all backend constructors and detect_aborted_start. Handles intentional shutdown in wait functions. Fixes VirtualBox current_state to detect stopped state immediately. Fixes #4456 [daemon] Move parsing to backend constructors [backends] Add shutdown detection to all Created expects_shutdown_from_cloud_init() helper function. Implemented in all backend constructors and detect_aborted_start. Handles intentional shutdown in wait functions. [review] Address review feedback - Restore missing 'starting' state check in VirtualBox current_state - Fix VirtualBox current_state to detect stopped state immediately - Remove duplicate TODO comment in wait_for_cloud_init - Remove extra newline in wait_for_cloud_init - Add if constexpr check to only treat IntentionalShutdownException as success for LaunchRequest, not StartRequest [review] Fix whitespace and test failure - Remove trailing whitespace (per GIT9) - Add expected_shutdown check to detect_aborted_start - Fixes BaseVM.waitForCloudInitVMDownReconnects test

- Remove early return for intentional shutdown during launch - Save mount configuration even when VM is stopped - Skip mount activation if VM not running - Fix missing braces in detect_aborted_start - Apply clang-format to all modified files Ensures mounts are ready when VM starts later. All tests passing including BaseVM.waitForCloudInitVMDownReconnects.

Add extra current_state() call expectation to match additional state check in wait_for_cloud_init.

deepakshirkem · 2026-06-02T19:08:59Z

        .WillOnce(Return(mp::VirtualMachine::State::running))    // when 1st waiting for cloud-init
        .WillOnce(Return(mp::VirtualMachine::State::restarting)) // when retrying to ssh
        .WillOnce(Return(mp::VirtualMachine::State::running));   // back waiting for cloud-init
+        .WillOnce(Return(mp::VirtualMachine::State::running));   // back to cloud-init


Added this call. Do you think this is the right approach? The test is passing locally, but I observed that it is failing in CI.

tobe2098 · 2026-06-10T19:35:52Z

Very well done @deepakshirkem. Thank you for your patience :D. I think the solution is achieved well, but the second commit's changes are not necessary as I stated in my previous message. The mounts for multipass launch are performed through an external multipass mount call, not through the async_* function. Otherwise it looks good to me :).

Copilot

Pull request overview

This PR improves multipass launch behavior when user-provided cloud-init intentionally powers off the VM (via power_state), by detecting that intent and treating the resulting shutdown as a successful initialization outcome rather than waiting for SSH until timeout.

Changes:

Add cloud-init YAML inspection to detect power_state.mode: poweroff|halt (intentional shutdown expectation).
Propagate the “expected shutdown” behavior into backend VMs and BaseVirtualMachine startup/wait logic via a new IntentionalShutdownException.
Teach the daemon’s launch flow to treat IntentionalShutdownException as success for launch (while still failing non-launch starts).

Reviewed changes

Copilot reviewed 11 out of 11 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
tests/unit/test_base_virtual_machine.cpp	Updates unit test expectations related to cloud-init wait behavior.
src/utils/utils.cpp	Adds helper to detect expected shutdown from cloud-init YAML.
include/multipass/utils.h	Exposes the new cloud-init shutdown detection helper in the public utils API.
src/platform/backends/shared/base_virtual_machine.h	Adds an `expected_shutdown` flag to the base VM implementation.
src/platform/backends/shared/base_virtual_machine.cpp	Throws `IntentionalShutdownException` on shutdown during startup when expected; adjusts SSH/cloud-init wait paths.
include/multipass/exceptions/intentional_shutdown_exception.h	Introduces a dedicated exception type for intentional shutdown during initialization.
src/daemon/daemon.cpp	Catches `IntentionalShutdownException` and treats it as success for launch operations.
src/platform/backends/qemu/qemu_virtual_machine.cpp	Initializes `expected_shutdown` from cloud-init YAML in QEMU backend.
src/platform/backends/virtualbox/virtualbox_virtual_machine.cpp	Initializes `expected_shutdown` from cloud-init YAML in VirtualBox backend.
src/platform/backends/hyperv/hyperv_virtual_machine.cpp	Initializes `expected_shutdown` from cloud-init YAML in Hyper-V backend.
src/platform/backends/applevz/applevz_virtual_machine.cpp	Initializes `expected_shutdown` from cloud-init YAML in AppleVZ backend (and adds required include).

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

    EXPECT_CALL(vm, current_state)
        .WillOnce(Return(mp::VirtualMachine::State::running))    // when 1st waiting for cloud-init
        .WillOnce(Return(mp::VirtualMachine::State::restarting)) // when retrying to ssh
        .WillOnce(Return(mp::VirtualMachine::State::running));   // back waiting for cloud-init
+        .WillOnce(Return(mp::VirtualMachine::State::running));   // back to cloud-init


+    auto action = [this]() -> utils::TimeoutAction {
+        auto vm_state = current_state();
+
+        if (vm_state == State::stopped || vm_state == State::off)
+        {
+            if (expected_shutdown)
+            {
+                mpl::log(mpl::Level::info, vm_name, "VM powered off as configured in cloud-init");
+                throw IntentionalShutdownException(vm_name);
+            }
+            else
+            {
+                mpl::log(mpl::Level::error, vm_name, "VM stopped unexpectedly");
+                throw StartException(vm_name, "VM stopped unexpectedly");
+            }
+        }
+
+        return try_to_ssh();
+    };


        detect_aborted_start();
+
+        auto vm_state = current_state();
+        if (vm_state == State::stopped || vm_state == State::off)
+        {
+            if (expected_shutdown)
+            {
+                mpl::log(mpl::Level::error, vm_name, "VM powered off as configured in cloud-init");
+                throw IntentionalShutdownException(vm_name);


+bool mp::utils::expects_shutdown_from_cloud_init(const YAML::Node& user_data_config)
+{
+    if (user_data_config["power_state"])
+    {
+        auto ps = user_data_config["power_state"];
+        if (ps["mode"])
+        {
+            std::string mode = ps["mode"].as<std::string>();
+            return (mode == "poweroff" || mode == "halt");
+        }
+    }
+    return false;
+}


 namespace
 {
 constexpr static auto log_category = "applevz-vm";
 } // namespace
+#include <multipass/utils.h>



+#pragma once
+
+#include <stdexcept>
+#include <string>
+
+namespace multipass
+{
+
+class IntentionalShutdownException : public std::runtime_error
+{
+public:
+    explicit IntentionalShutdownException(const std::string& name)
+        : std::runtime_error{
+            "Instance '" + name +
+            "' stopped intentionally during initialization "
+            "(cloud-init power_state directive)"} {}
+};
+
+}


+        if (expected_shutdown)
+        {
+            throw IntentionalShutdownException(vm_name);
+        }


tobe2098

Hi again @deepakshirkem, I just noticed that the approach we went for has a small flaw. The issue itself is more complex than expected. Would you mind if I do some additional work on top of your commits? I believe the problem will require more extensive thought but I want to keep your contributions. What do you think?

tobe2098 · 2026-06-10T19:44:13Z

@@ -314,8 +337,23 @@ void mp::BaseVirtualMachine::wait_until_ssh_up(std::chrono::milliseconds timeout

 void mp::BaseVirtualMachine::wait_for_cloud_init(std::chrono::milliseconds timeout)
 {
-    auto action = [this] {
+    auto action = [this]() -> mpu::TimeoutAction {
        detect_aborted_start();
+
+        auto vm_state = current_state();
+        if (vm_state == State::stopped || vm_state == State::off)
+        {
+            if (expected_shutdown)
+            {
+                mpl::log(mpl::Level::error, vm_name, "VM powered off as configured in cloud-init");
+                throw IntentionalShutdownException(vm_name);
+            }
+            else
+            {
+                mpl::log(mpl::Level::error, vm_name, "VM stopped unexpectedly during cloud-init");
+                throw StartException(vm_name, "VM Stopped unexpectedly during cloud-init");
+            }
+        }
        try
        {
            ssh_exec("[ -e /var/lib/cloud/instance/boot-finished ]");


I just noticed an additional problem. expected_shutdown remains as true after launching and stopping which means that on a second start, a failed start would appear as a intentional shutdown.

deepakshirkem · 2026-06-10T19:52:17Z

Hi again @deepakshirkem, I just noticed that the approach we went for has a small flaw. The issue itself is more complex than expected. Would you mind if I do some additional work on top of your commits? I believe the problem will require more extensive thought but I want to keep your contributions. What do you think?

Hi @tobe2098, Of course! You can build on top of these commits. I'm always available if you need anything from my side

deepakshirkem · 2026-07-08T08:50:24Z

Hi @tobe2098, I accidentally deleted my fork repository, which caused this PR to be closed. I still have all the changes locally. Would you like me to create a new PR with the same changes?

tobe2098 · 2026-07-08T09:12:07Z

Yes, if possible do so please. I will pull them into another branch

tobe2098 self-requested a review February 23, 2026 10:23

deepakshirkem force-pushed the fix/cloud-init-shutdown-support branch from ab66f47 to cd4916d Compare March 15, 2026 19:32

tobe2098 requested changes Mar 16, 2026

View reviewed changes

tobe2098 requested changes Mar 19, 2026

View reviewed changes

deepakshirkem requested a review from tobe2098 March 21, 2026 12:09

tobe2098 requested changes Apr 7, 2026

View reviewed changes

deepakshirkem requested a review from tobe2098 April 9, 2026 20:01

deepakshirkem force-pushed the fix/cloud-init-shutdown-support branch 4 times, most recently from 45d00d1 to b6219ba Compare April 26, 2026 20:58

tobe2098 requested changes May 8, 2026

View reviewed changes

deepakshirkem force-pushed the fix/cloud-init-shutdown-support branch 3 times, most recently from c3efd4b to 5de7d61 Compare May 9, 2026 14:27

deepakshirkem requested a review from tobe2098 May 9, 2026 14:30

tobe2098 requested changes Jun 2, 2026

View reviewed changes

deepakshirkem added 3 commits June 3, 2026 00:34

[test] Update waitForCloudInitVMDownReconnects test

b4e1a2e

Add extra current_state() call expectation to match additional state check in wait_for_cloud_init.

deepakshirkem force-pushed the fix/cloud-init-shutdown-support branch from 5de7d61 to b4e1a2e Compare June 2, 2026 19:04

deepakshirkem requested a review from tobe2098 June 2, 2026 19:05

deepakshirkem commented Jun 2, 2026

View reviewed changes

xmkg changed the title ~~[deamon] Handle cloud-init intentional shutdown~~ [daemon] Handle cloud-init intentional shutdown Jun 2, 2026

tobe2098 requested a review from Copilot June 10, 2026 19:36

Copilot started reviewing on behalf of tobe2098 June 10, 2026 19:36 View session

tobe2098 marked this pull request as draft June 10, 2026 19:36

tobe2098 marked this pull request as ready for review June 10, 2026 19:36

Copilot AI reviewed Jun 10, 2026

View reviewed changes

tobe2098 requested changes Jun 10, 2026

View reviewed changes

tobe2098 self-assigned this Jul 2, 2026

deepakshirkem closed this by deleting the head repository Jul 7, 2026

deepakshirkem mentioned this pull request Jul 8, 2026

Fix/cloud init shutdown support #5038

Open

Uh oh!

Conversation

deepakshirkem commented Feb 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Description

What does this PR do?

Why is this change needed?

Implementation Details

Related Issue(s)

Testing

Manual testing:

Screenshots (if applicable)

Checklist

Additional Notes

Uh oh!

deepakshirkem commented Feb 23, 2026

Uh oh!

tobe2098 commented Feb 27, 2026

Uh oh!

deepakshirkem commented Mar 15, 2026

Uh oh!

codecov Bot commented Mar 16, 2026

Codecov Report

Uh oh!

tobe2098 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deepakshirkem commented Mar 18, 2026

Uh oh!

tobe2098 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deepakshirkem commented Mar 21, 2026

Uh oh!

tobe2098 commented Apr 7, 2026

Uh oh!

tobe2098 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deepakshirkem commented Apr 9, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deepakshirkem May 9, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

deepakshirkem commented May 9, 2026

deepakshirkem commented Feb 21, 2026 •

edited

Loading

deepakshirkem May 9, 2026 •

edited

Loading