The safest assumption to make here is that the configuration is not applied completely and you should try again once the network is back. You can set things up to work without the network, but why go to that work when it will try again for you in a few minutes?
Chef tends to be run in the client-server mode as you describe so the
chef-client agent on the "controlled" machine would keep running. It would get stuck when it needed to get cookbooks or figure out which roles were assigned. It will eventually time out and the chef run will fail. Then it would try again in a few minutes. By default the agent tries to do a chef run every 30 minutes.
If you're using
chef-zero instead of the client-server style of chef then you could have everything staged on the "controlled" machine so that any network interruption wouldn't break it because of chef itself. You might still have network dependancies in the cookbooks used.
Ansible ssh // push
Ansible started off by doing everything via
ssh. In this style of Ansible the completion state on the "controlled" node would be unknown but from the perspective of the user running ansible that node would clearly need to be retried. Ansible creates a file for you with all of the hosts that need to be retried.
Ansible in cron // pull
If you're running Ansible from a
cron job then it will face similar issues to the classic
chef-client. The node will need to phone home to find roles and updates, but it will time out and retry later.