Ciphertext length in TLS 1.3 additional data RFC8846 says:
..and the additional data input is the record header.

   I.e.,

      additional_data = TLSCiphertext.opaque_type ||
                        TLSCiphertext.legacy_record_version ||
                        TLSCiphertext.length

But the length of the encrypted text (which is the length field in the record header) is not known until the encryption is done. It looks to me like a chicken and egg situation.
Question is, what I am missing here ?
Thanks.
the length of the encrypted text (which is the length field in the record header) is not known until the encryption is done

The length of the ciphertext is known as soon as the length of the plaintext is known. This is true for any non-broken encryption mechanism. An adversary can easily observe the length of the ciphertext, and if that allows the adversary to deduce anything about the plaintext other than its length, it's a weakness in the encryption.
All the standard AEAD mechanisms for TLS 1.3 (CCM, GCM, ChaCha20+Poly1305) are constructed in such a way that the ciphertext is the application of a stream cipher to the plaintext, followed by a one-time MAC (the authentication tag). Thus the length of the ciphertext is the length of the plaintext plus the tag length of the mechanism (16 for GCM, CCM and ChaCha20+Poly1305; 8 for CCM_8). RFC 8846 is worded in a more general way that would allow AEAD mechanisms with a more complex construction. But whatever the mechanism is, there is a way to calculate the ciphertext length from the plaintext length, although it could be harder than adding a constant.