How can I test the atomic push feature in Appsmith?

[hearty vortex]

Hi, I'm trying to test the atomic push behavior in Appsmith, but I can't reproduce a partial commit or conflict scenario.

Here’s what I’ve tried:

I disabled automatic pull so that I could manually push and see a conflict.

I created conflicting changes in the same branch from two users (User A and User B).

When User B pushes without pulling, Appsmith shows:
“Git push failed for pending upstream changes... we will pull and push to your repo.”
→ But it still pulls automatically even though I expected it not to.

My goal:
I want to verify that when atomic push is enabled, no partial data is pushed in case of conflict. And when atomic push is disabled, partial commits can happen.

Questions:

How exactly can I simulate a Git conflict that will trigger atomic push logic?

Is there a way to disable both automatic pull and still push manually (for testing atomic push)?

Does Appsmith currently support disabling atomic push through environment config or feature flag?

Is there a test repo or known setup where atomic push behavior is verifiable?

Any help or clarification would be really appreciated 🙏

[rancid gull]

Hey There,

We've registered your query, and our team will get back to you soon.

Regards,
Pranav

[rancid gull]

Hello! I'm AppsmithBot, your support assistant for building applications on the Appsmith platform. How can I assist you today?

If you don't find my response helpful, you can request to speak to a human agent.

[hearty vortex]

I'm trying to test the atomic push behavior in Appsmith, but I can't reproduce a partial commit or conflict scenario.

[rancid gull]

To test atomic push behavior in Appsmith, you need to ensure that your data source supports transactions, as Appsmith relies on the underlying database's transaction capabilities to handle atomic operations. Here are some steps you can follow to test this:

1. Ensure Transaction Support: Verify that your database supports transactions. Databases like PostgreSQL and MySQL support transactions, while some NoSQL databases might not.

2. Create a Test Scenario:

• Set up a scenario where multiple operations need to be performed as a single transaction.
• For example, you can create a query that updates multiple tables or rows.

3. Simulate a Conflict:

• Introduce a deliberate error in one of the operations to simulate a conflict or partial commit scenario.
• For instance, try to update a non-existent row or violate a unique constraint.

4. Observe the Behavior:

• Run the query and observe if the entire transaction is rolled back in case of an error.
• Check the database to ensure no partial updates were committed.

5. Use Appsmith's Debugging Tools:

• Utilize Appsmith's debugging tools to log and monitor the query execution and any errors that occur.

If you have specific queries or need further assistance, feel free to share more details!

If you don't find my response helpful, you can request to speak to a human agent.

[hearty vortex]

Thanks for your response!

Just to clarify — I’m actually referring to Git-level atomic push behavior in Appsmith, not database transactions.

My use case is around testing how Appsmith handles Git conflicts and whether it pushes all or none of the changes when a push fails. Specifically:

When atomic push is enabled, I expect no partial changes to be committed to the Git repo.

When atomic push is disabled, I want to confirm whether some changes may still get pushed, even if the whole push fails due to upstream conflicts.

I’ve tried creating conflicting changes from two users, but Appsmith automatically pulls before pushing, so I can’t clearly test atomic push behavior.

Questions:

Is there a way to force a push (and skip auto-pull) so I can simulate this properly?

Is there a feature flag or env variable like APPSMITH_GIT_ATOMIC_PUSH that controls this behavior?

Is this feature only available in self-hosted deployments?

Would love any guidance on how to test this properly. 🙏

[rancid gull]

To address your questions regarding Git-level atomic push behavior in Appsmith:

1. Force a Push Without Auto-Pull: Currently, Appsmith automatically pulls changes before pushing to ensure that the local branch is up-to-date with the remote branch. There isn't a built-in feature to skip this auto-pull step directly within Appsmith's UI. This behavior is designed to prevent conflicts and ensure consistency.

2. Feature Flag or Environment Variable: There is no specific environment variable like APPSMITH_GIT_ATOMIC_PUSH mentioned in the documentation that controls atomic push behavior. The Git operations in Appsmith are generally designed to ensure that either all changes are pushed successfully or none are, to maintain consistency.

3. Availability in Self-Hosted Deployments: The Git integration features, including handling of conflicts and push behaviors, are available in both cloud and self-hosted deployments of Appsmith. However, specific configurations or customizations might be more feasible in self-hosted environments where you have more control over the server settings.

For testing purposes, you might consider setting up a controlled environment where you can manually simulate conflicts by making changes directly in the remote repository outside of Appsmith, then attempting to push from Appsmith to observe the behavior.

If you need further assistance or have specific scenarios you want to test, feel free to reach out!

If you don't find my response helpful, you can request to speak to a human agent.

[hearty vortex]

Thanks so much for the clarification!

So just to confirm:

Appsmith always ensures a full or none push to the Git repo (i.e., atomic push is always enforced).

There’s no way to disable atomic push even in self-hosted setups (e.g., to allow partial changes in case of upstream conflicts).

And auto-pull before push is currently mandatory to prevent history divergence.

That helps a lot. I was trying to simulate a partial push scenario by disabling atomic push, but looks like that behavior isn’t supported by design — which makes sense for consistency.

I might experiment with conflict simulation at the Git level (e.g., commit directly on remote) as you suggested.

Thanks again!

[rancid gull]

You're welcome! Yes, you've got it right:

• Appsmith ensures that Git operations are atomic, meaning it's designed to push all changes or none, maintaining consistency.
• There isn't an option to disable atomic push, even in self-hosted setups, as this is part of the design to prevent partial changes and ensure data integrity.
• The auto-pull before push is mandatory to prevent history divergence and conflicts.

Simulating conflicts at the Git level by making changes directly on the remote is a good approach to test how Appsmith handles such scenarios. If you have any more questions or need further assistance, feel free to ask. Happy experimenting!

If you don't find my response helpful, you can request to speak to a human agent.

[hearty vortex]

Hi again! Quick follow-up:

I noticed there's a setting in the Admin panel called "Allow atomic push".

But based on the explanation earlier, Appsmith always enforces atomic push, and there’s no way to disable it — even in self-hosted setups.

So my question is:

What’s the purpose of this setting if atomic push behavior is enforced anyway?

Does it have an effect only in certain versions or environments (e.g. self-hosted or enterprise)?

Or is it a legacy setting with no impact in current versions?

Just trying to understand how this flag works in practice. Thanks again!

[rancid gull]

The "Allow atomic push" setting in the Admin panel is likely a configuration option that provides flexibility in certain environments or versions of Appsmith. However, based on the current design and documentation, Appsmith enforces atomic push behavior to ensure consistency and prevent partial commits. This setting might be a legacy option or intended for specific use cases that are not commonly documented.

Here are some possibilities regarding this setting:

1. Legacy or Specific Use Case: It might be a legacy setting that was used in earlier versions or for specific enterprise environments where different Git behaviors were required.

2. Environment-Specific: It could be relevant in certain self-hosted or enterprise environments where administrators have more control over Git operations.

3. No Current Impact: In the current versions, it might not have any impact due to the enforced atomic push behavior by design.

For precise details, especially if this setting is critical for your use case, I recommend reaching out to Appsmith support or checking with the latest documentation updates. If you have further questions or need more assistance, feel free to ask!

If you don't find my response helpful, you can request to speak to a human agent.