How to manage AI execution errors

[Monty_Bagati]

Hi @nghi.phan : is the issue resolved ?

[nghi.phan]

@Monty_Bagati

I am not able to add automated test case that flowed from katalon studio to Azure Repos and then in true platform and when i try to create a test suite and add that test case under that , it fails with 500 server error. pls note that my PAT has all the read and write access and i have checked it writes properly to ADO

I have created a ticket here: https://katalon.atlassian.net/browse/KSR-11808

[nghi.phan]

Ticket has been created: https://katalon.atlassian.net/browse/KSR-11808

[Monty_Bagati]

No access

[nghi.phan]

I will share with you when we have more details. The tickets are for internal tracking.

Thank you

[Monty_Bagati]

ok , you shared the link so i thought it must be for us as well

[nghi.phan]

Hi Monty,

Thanks for the detailed report — the screenshot made this much faster to trace.

Our team dug into it and the schedule behind those rows is configured as a manual test run. On a manual schedule the cron fires and creates the work item with your selected cases, then stops there and waits for an explicit start. So NOT_STARTED is accurate but badly worded: it means “waiting on a person,” not “the system tried and failed.” We checked both the 25 and 26 Jul entries and there’s no automation job, manual-execution record, or TestCloud execution behind either one. Nothing was attempted, so there’s no downstream failure to find.

The “Temporary Test Suite” naming threw us off initially too. It’s just the persisted container for whichever manual cases were selected at schedule creation — not related to the run sitting idle.

So either start it via Run now / Run with TestPak when you want it, or recreate the schedule as an automated run against a real test suite with an environment and agent if you want it unattended.

Please let us know your take on this

Bella

[Monty_Bagati]

Thanks for digging in, that explanation makes sense.

Couple of follow-ups though, since “no failure to find” isn’t quite the same as “working as intended”:

1. Was Manual trigger something I actually selected, or is it the silent default when a schedule uses ad-hoc/temporary cases instead of a saved suite? If it’s a default, that’s the real issue here, I genuinely thought I’d set up unattended automation.

2. Either way, having NOT_STARTED sit next to AUTOMATED rows for days with no alerting is still a gap worth closing. Is there any plan for a “scheduled but never executed” alert? Right now the only way to catch this is someone noticing a stale row, and that’s not something I’d want to depend on for real regression coverage.

[Monty_Bagati]

Confusion 1 : Sprints sync from SaaS Jira

Hello @nghi.phan : Could you please check why I am not able to sync Sprints from my JIRA account.

All my integrations are in place.

I am only able to sync the releases from JIRA , what am i dong wrong here ?

[Monty_Bagati]

Ignore this as it reflects in the “timeline” tab and not in “Releases” tab

[nghi.phan]

Hi True Builders

I want your thoughts on before we do anything.

Right now, product feedback and bug reports live here inside this group. I’d love to open them up to the whole community — public threads that anyone can read, comment on, and add to.

On top of that, we’d run regular events where the community votes on which items they want prioritised, so the product team can see what actually matters to people, not just what shouts loudest.

Why I think it’s worth doing:

• More eyes means faster confirmation of bugs and better repro steps
• People see their feedback going somewhere, which builds trust
• You all get a bigger audience backing the things you raise

Please let me know if you are ok with this ^^

Thanks

Bella

[dineshh]

good one. i’m ok

[depapp]

it’s a good idea Bella @nghi.phan

[arvind.choudhary]

Good call Bella

[akshay_sartabe]

agree more audience … more confirmation