# Pitfalls to avoid

These are corner cases which should not happen in the common usages, but if they do, what happens may be very confusing. Here are some tips.

## When my application exits uncleanly, it still appears to be online to other resources

Congratulations! You are using a server with support for Stream Management. As you might know, `aioxmpp` transparently and automatically uses Stream Management whenever it is available. This means that `aioxmpp.Client` instances must always be `aioxmpp.Client.stop()`-ed properly, so that the stream can be shut down to prevent it from lingering on the server side. The preferred way to do this is to use the `aioxmpp.Client.connected()` asynchronous context manager:

    client = aioxmpp.Client()
    with client.connected() as stream:
        # stream is the aioxmpp.stream.StanzaStream of the client
        # do something

When the context manager is left (either with an exception or normally), the connection is closed cleanly.

If the context manager cannot be used, other means to ensure that `aioxmpp.Client.stop()` is called and the client is given enough time to shut the connection down cleanly need to be applied. This can be done in the following manner:

    if client.running:
        fut = asyncio.Future()
        client.on_stopped.connect(fut, client.on_stopped.AUTO_FUTURE)
        client.on_failure.connect(fut, client.on_failure.AUTO_FUTURE)
        try:
            yield from fut
        except:
            # we are shutting down, ignore any exceptions from on_failure
            pass

Ensure that this snippet is executed before the application exits, even in the case that an error occured.

Note

You may be asking “But why is the Connection Reset by Peer the server must be getting after my application crashed not enough?”. The whole reason for Stream Management is to make it possible for the server to ignore such errors which may very well occur if network connectivity is briefly interrupted (for example when switching between networks, or your ISP has a power failure, or you reboot your modem or something like that). Stream Management allows to resume an uncleanly closed stream up to a certain timeout (as (possibly dynamically) determined by the server). Making errors such as Connection Reset by Peer break such a stream would defeat the purpose of Stream Management.

Note

As of version 0.9, you can disable the resumption capaibility of Stream Management using the `Client.resumption_timeout` attribute. However, that alone is no guarantee that sessions die quickly; it still depends a lot on the way in which the network connection got interrupted and whether or not the server is sending data to the (disconnected) client.

There are other timeouts, such as the ones from TCP, at play here which need to be tweaked properly on the server-side. How to do so is out of scope for aioxmpp.

(If you happen to find a client-side way, e.g. in another XMPP library, to achieve the behaviour of letting the session die quickly in case of a hard disconnect (e.g. a pulled cable), let me know. I’m quite convinced that this is impossible, so I’d like to be proven wrong.)

## I am trying to connect to a bare IP and I get a DNS error

For example, when trying to connect to `192.168.122.1`, you may see:

    Traceback (most recent call last):
      File "/home/horazont/aioxmpp/aioxmpp/network.py", line 272, in repeated_query
        raise_on_no_answer=False
      File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__
        yield self  # This tells Task to wait for completion.
      File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
        value = future.result()
      File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
        raise self._exception
      File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
        result = self.fn(*self.args, **self.kwargs)
      File "/home/horazont/.local/lib/python3.4/site-packages/dns/resolver.py", line 1051, in query
        raise NXDOMAIN(qnames=qnames_to_try, responses=nxdomain_responses)
    dns.resolver.NXDOMAIN: None of DNS query names exist: _xmpp-client._tcp.192.168.122.1., _xmpp-client._tcp.192.168.122.1.

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "/home/horazont/aioxmpp/aioxmpp/node.py", line 710, in _on_main_done
        task.result()
      File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
        raise self._exception
      File "/usr/lib/python3.4/asyncio/tasks.py", line 233, in _step
        result = coro.throw(exc)
      File "/home/horazont/aioxmpp/aioxmpp/node.py", line 868, in _main
        yield from self._main_impl()
      File "/home/horazont/aioxmpp/aioxmpp/node.py", line 830, in _main_impl
        logger=self.logger)
      File "/home/horazont/aioxmpp/aioxmpp/node.py", line 337, in connect_xmlstream
        logger=logger,
      File "/home/horazont/aioxmpp/aioxmpp/node.py", line 142, in discover_connectors
        "xmpp-client",
      File "/home/horazont/aioxmpp/aioxmpp/network.py", line 318, in lookup_srv
        **kwargs)
      File "/home/horazont/aioxmpp/aioxmpp/network.py", line 280, in repeated_query
        "nameserver error, most likely DNSSEC validation failed",
    aioxmpp.network.ValidationError: nameserver error, most likely DNSSEC validation failed

You should be using `aioxmpp.Client.override_peer` or an equivalent mechansim. Note that the exception will still occur if the connection attempt to the override fails. Bare IPs as target hosts are generally not a good idea.