As iegomez already explained, join requests are sent based on the behavior of the firmware alone.
It’s a little unclear if Class C necessarily implies OTAA. The following passage in the LoRaWan spec could be read as lightly assuming that it does:
Note: There is not specific message for a node to tell the server that it is a Class C node. It is up to the application on server side to know that it manages Class C nodes based on the contract passed during the join procedure.
But there does not appear to be any actual technical reason forcing that. The only “interaction” for setting up class C are some new MAC commands.
So really this seems to come down to the assumptions made by whoever wrote your node-side firmware.
If this node is sending join requests, then it is not correctly operating as ABP
You could confirm class C behavior by seeing reception of RX2 downlink transmissions outside the normal time limits, or probably better by adding logging into the node firmware to say when it enters/exits that extended RX2 mode.
I do not know if this is still of interest, but the answer is - Class C and ABP are ok. It is up to firmware how it behaves when turned on - does in pull OTAA creds and go OTAA, or stored ABP and try to continue with these stored credentials.
My recommendation would be to turn off fcnt verification on server side. It is usually not feasible to store running fcnt to flash and your firmware most probably is not doing that.
But, YMMV. I can try to help more if you have some details to provide and make your question more specific.