One of the key differences between HTTP/2 and HTTP/3 is the switch from TCP to UDP.
As I understand it, TCP verifies data integrity by verifying that no data packets have been lost. Any packets lost are requested again to ensure all data is correctly received.
For UDP, there is no such validation. If packets are lost then so be it.
That being said, if I make a request on HTTP/3 and a packet is lost, is there a mechanism to ensure I get all my data, or will there be a risk that my response will be missing data packets?
If packets are lost then so be it.
No, with UDP it is no "so be it" but it is up to the protocol on top of UDP to care about packet loss, duplication and reordering or not to care. For example with RTP (real time audio in VoIP etc) it is fine to have some packet loss, since there is no use for later arriving packets anyway (audio must be low latency). And reordering and duplication is handled in RTP with protocol-inherent sequence numbers.
For HTTP/3 instead data loss is not acceptable. HTTP/3 is build on top of QUIC which is build on top of UDP. Packet loss is handled within QUIC (see QUIC Loss Detection and Congestion Control). Thus HTTP/3 is basically build on top of a reliable transport (QUIC) the same as HTTP/1 and HTTP/2 are build on top of an reliable transport layer (TCP).