[HOLD for payment 2024-07-24] Verify Podfile action is flaky

[mountiny]

Problem

On some PRs, we have noticed a Verify Podfile action failing with illegitimate reasons. For example this one. This is causing a slowdown in development.

The error is:

script: tcgetattr/ioctl: Operation not supported on socket

Solution

Solve this flakiness and fix the actions.

Issue Owner

Current Issue Owner: @mountiny

[melvin-bot]

Triggered auto assignment to @garrettmknight (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.

[mountiny]

@fabioh8010 has got a fix for this hopefully

[mountiny]

@fabioh8010 while we try to merge your fix fast, do you think you could (or someone from your team) still explore how to fix this while maintaining the colouring of the output? I assume that is a nice-to-have thing to improve DX

[kabeer95]

Proposal: Fix Flaky Podfile Action

Problem Statement: The Podfile action is flaky, resulting in inconsistent behavior and errors.

Root Cause: The root cause of the problem is that the loginList data in ContactMethodsPage contains unnecessary login data with partnerName: "chat-expensify-com", which is not needed in this page.

Changes to Solve the Problem: To solve the problem, I propose the following changes:

Create a Login List Selector Create a login list selector that removes the unnecessary login data with partnerName: "chat-expensify-com" and use it in ContactMethodsPage.

Code Changes:

// Create a login list selector
const loginListSelector = (data) => {
return Object.fromEntries(
Object.entries(data).filter(([key, value]) => value.partnerName !== 'chat-expensify-com')
);
};

// Use the selector in ContactMethodsPage
loginList: {
key: ONYXKEYS.LOGIN_LIST,
selector: loginListSelector,
},
Alternative Solutions Explored:

Use Partner ID to Filter: Instead of using partnerName !== 'chat-expensify-com' to filter the login data, we can use partnerID if this property is available. This approach may be more robust and flexible.
By implementing this solution, we should be able to fix the flaky Podfile action and ensure consistent behavior in ContactMethodsPage

[fabioh8010]

@fabioh8010 while we try to merge your fix fast, do you think you could (or someone from your team) still explore how to fix this while maintaining the colouring of the output? I assume that is a nice-to-have thing to improve DX

Sure, I will continue investigations on this 🫡

One question: Do you think we need this colouring of the patch-package result on the CI too?

[melvin-bot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[melvin-bot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.7-8 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• [No QA] Simplify applyPatches script #45189

If no regressions arise, payment will be issued on 2024-07-24. 🎊

[melvin-bot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@mountiny] The PR that introduced the bug has been identified. Link to the PR:
• [@mountiny] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@mountiny] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@mountiny] Determine if we should create a regression test for this bug.
• [@mountiny] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@garrettmknight] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[fabioh8010]

@mountiny PR is up -> #45615

[melvin-bot]

Skipping the payment summary for this issue since all the assignees are employees or vendors. If this is incorrect, please manually add the payment summary SO.

[garrettmknight]

@mountiny we good to close this yeah?

[mountiny]

all good now