[$250] An error occurred while loading more messaged appear when opening a report

[m-natarajan]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Version Number: Reproducible in staging?: need reproduction Reproducible in production?: need reproduction If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: If this was caught during regression testing, add the test name, ID and link from TestRail: Email or phone of affected tester (no customers): Logs: https://stackoverflow.com/c/expensify/questions/4856 Expensify/Expensify Issue URL: Issue reported by: @flodnv Slack conversation (hyperlinked to channel name): Expensiry - Migrate

Action Performed:

1. Have a previously paid report migrated
2. Open the report in NewDot

Expected Result:

Report opens with no issues

Actual Result:

An error occurred while loading more messages. -- I don't think there's any more to load. licking on Try again results in the same.

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• [ ] Android: Standalone
• [ ] Android: HybridApp
• [ ] Android: mWeb Chrome
• [ ] iOS: Standalone
• [ ] iOS: HybridApp
• [ ] iOS: mWeb Safari
• [x] MacOS: Chrome / Safari
• [ ] MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence


View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021863637943435459036
• Upwork Job ID: 1863637943435459036
• Last Price Increase: 2024-12-02

Issue Owner

Current Issue Owner: @Ollyws

[ansibot]

Files identified in the description:

• lib/ansible/modules/include_tasks.py

If these files are incorrect, please update the component name section of the description or use the component bot command.

[balous]

I need similar thing - our inventory contains hosts that compose multiple clusters. Some tasks need to be run just once per cluster, we use run_once: true for such tasks. But there is a problem - if ansible play contains hosts accross different clusters, the task is performed for just one of the clusters, not for all clusters.

Recently, I noticed following behavior of include_tasks/include_role and loop combination:

        - name: Create users
          ansible.builtin.include_tasks:
            file: users.yaml
          loop: "{{ [ cluster_name ] }}"

When include_tasks is looped across list (for this purpose I use just a single element), where the element contain different value across different groups of hosts, these hosts are divided to groups by the value of the element. The groups are than run in sequence while hosts in the group are run in parallel. Inside users.yaml, run_once: true is used to not create the same user three times.

The problem of this solution is that it is not documented (I was unable to find it's doc) so we're affraid it might stop working in some future Ansible update.

As I think about it, I came to conclusion that it would be handy if run_once semantics is extended from bool to general expression. The behavior would be that ansible chooses just one host for each of the values the expression evaluates to (except false to retain compatibility with current semantics).

Does this make sense?

[bcoca]

Hi!

Thanks very much for your submission to Ansible. It means a lot to us that you've taken time to contribute.

Unfortunately, we're not sure if we want this feature in the program, parallelism is normally defined at the play/strategy level and the engine is not designed to change this mid play. First, the run_once functionality is implemented not by increasing/changing parallelism but by skipping the task for all hosts after the first, this would not work for this case. The work of creating the tasks per host would still occur as includes are not real tasks but engine directives that update the iterator at runtime.

However, we're absolutely always up for discussion. Because this project is very active, we're unlikely to see comments made on closed tickets and we lock them after some time. If you or anyone else has any further questions, please let us know by using any of the communication methods listed in the page below:

• https://docs.ansible.com/ansible/latest/community/communication.html

In the future, sometimes starting a discussion on the development list prior to implementing a feature can make getting things included a little easier, but it's not always necessary.

Thank you once again for this and your interest in Ansible!