Should already be the case.

Note that this can occur if you have enabled the FBW API connection and someone else is already using your flight number, it will show FLT NUMBR IN USE.

Thanks @2hwk for your suggestion, but this isn't the cause of my issue.
I made sure that only MSFS is running on my machine, and the issue persists as described above.
There also is NO message of FLT NUMBR IN USE.

Does this happen for different flight numbers? Even flight numbers that wouldn't exist IRL? How about different origin and dest airports? I will try to reproduce but want to make sure any variables are accounted for.

Edit: Testing with CYUL -> CYOW. I can reproduce the behaviour, and I've noticed a few other strange things as well:

1. Sometimes after a while, the flight number is accepted on the INIT page after all.
2. If I press the softkey with nothing in the scratchpad, nothing happens (except a small clicking sound). If I press it twice in quick succession, it will first say FORMAT ERROR, and when I clear that, the scratch pad is pre-populated with the correct flight number. Then, if I press the softkey to enter it, it just gets cleared from the scratchpad and not entered. After doing this a few times, I pressed the softkey one more time, and the flight number was filled out with nothing in the scratchpad.

It's delayed because when you enter a flight number an async request goes off to the FBW API to "logon". That comes back either normal and then the flight number gets populated, or you get the FLT NBR IN USE. I don't know if there's anything to request an immediate redraw of the CDU page when the normal response comes back which would explain why it seems delayed. I don't like the whole way it works personally; that's just not how the flight number field is supposed to work on an A320.

I've done this about 20 times now with different time delays, systems running, and even flight numbers. I've never seen FLT NBR IN USE. This isn't redraw-related, because when it doesn't accept any input, navigating away from the page and back doesn't change anything. I would expect to see calls to the FBW API in Coherent's network tab, but, at least when I'm looking at VCockpit08, I don't see those calls. I see the health checks and the calls to SimBrief though.

If this is a matter of the flight number being in use, that's fine, but something in that flow is broken.

Edit: Got it, it's the ATSU page that gets the message and doesn't get redrawn. After going back to it, I see FLT NBR IN USE. Might have been introduced in #7670

In summary, there is two issues here:

1. If the data request is initiated from the INIT page, the FLT NBR IN USE message doesn't get seen at all. It does say AOC ACT F-PLN UPLINK, so a curious pilot could go to that page to see what's up, but that's not exactly great UX for a system that we've sort of made up here.
2. If the data request is initiated from the AOC page, the message is received asynchronously and doesn't trigger a redraw.

Ah, the ATSU cannot send messages to the FMGC scratchpad (IRL and on the A32NX), so that might explain part of it. But the real ATSU does not send such a scratchpad message anyway. The flight number just immediately sets in the FMGC, and may or may not get sent to a ground station by the ATSU.

I've just tested again using flight YPPH - YMML, using real life data for flight number, and the issue persists.
And given that Headwind Simulations are using your framework for their Airbus, I also tried the same with the Headwind A339X (Pre-Release v0.6-alpha.4), and the same is happening there. ... In case that helps.

But I'm glad you can recreate it - thanks for persisting ;-).

Hello, had exact same issue with FLT NBR not populating, for every single flight for the last 2-3 weeks. At the same time I was getting a ;Reverse Proxy Error; message as well. Someone mentioned the reverse proxy message was to do with Hoppie. So I went into the EFB, disabled Hoppie, and now the FLT NBR populates again perfectly every time. Worth trying to replicate with Hoppie disabled... I also don't know if it was because my Hoppie logon code had expired as well. I will try tomorrow to renable hoppie but with a new logon code and see if that also works.

Hello, had exact same issue with FLT NBR not populating, for every single flight for the last 2-3 weeks. At the same time I was getting a ;Reverse Proxy Error; message as well. Someone mentioned the reverse proxy message was to do with Hoppie. So I went into the EFB, disabled Hoppie, and now the FLT NBR populates again perfectly every time. Worth trying to replicate with Hoppie disabled... I also don't know if it was because my Hoppie logon code had expired as well. I will try tomorrow to renable hoppie but with a new logon code and see if that also works.

If your Hoppie logon code had expired, then that's why you got the Reverse Proxy Error.

With the above comment, I tried the following:

• Create and retrieve a new Hoppie's ACARS registration
• Start a flight CAD at EDDM
• In the EFB, copy in the new ACARS registration.
• Leave ACARS as disabled (i.e. it was always disabled in my previous tests)
• Follow all steps as before -> FLT NBR is now populating

EXPECTED BEHAVIOUR

• FLT NBR should populate regardless of Validity of ACARS registration, and also regardless of ACARS being enabled or disabled.

To add on this, can you also prefill the flight number and altitude from a default MSFS plan when working on this???