I also get an unhandled exception in the maximum_connections_exceeded case:
Traceback (most recent call last):
File "/usr/lib/python2.7/dist-packages/gi/overrides/GLib.py", line 727, in <lambda>
func_fdtransform = lambda _, cond, *data: callback(channel, cond, *data)
File "/work/nsteel/projects/mopidy-dev/mopidy/mopidy/internal/network.py", line 122, in handle_connection
File "/work/nsteel/projects/mopidy-dev/mopidy/mopidy/internal/network.py", line 144, in reject_connection
logger.warning('Rejected connection from [%s]:%s', addr, addr)
IndexError: string index out of range
If we have this optional then we need some tests to verify that's OK. I'm getting:
ERROR 2017-07-04 15:52:46,569 [20285:MpdFrontend-14] pykka
Unhandled exception in MpdFrontend (urn:uuid:e87ce82e-f8b3-41ef-b9a1-5062480a5e92):
Traceback (most recent call last):
File "/work/nsteel/projects/mopidy-dev/pykka/pykka/actor.py", line 192, in _actor_loop
File "/work/nsteel/projects/mopidy-dev/mopidy/mopidy/mpd/actor.py", line 83, in on_start
File "/work/nsteel/projects/mopidy-dev/mopidy/mopidy/zeroconf.py", line 115, in publish
self.domain, self.host, dbus.UInt16(self.port),
TypeError: int() argument must be a string or a number, not 'NoneType'
In this particular case, does it make sense to advertise on zeroconf when it's a unix socket?
I don't believe the above snippet is supported. We do want to validate a Unix socket path in the exact same way we do any other path, it'd be nice to reuse that validation code. Ultimately, unix sockets are probably valid everywhere that a hostname would be so I'd say wrapping is ok. Any thoughts @adamcik, @jodal?
So I tried out the following for Hostname.deserialize to try and reuse the existing Path validation code. What do you think?
def deserialize(self, value, display=False):
if not value.strip():
socket_path = path.get_unix_socket_path(value)
if socket_path is not None:
return Path(not self._required).deserialize(socket_path)
raise ValueError('must be a resolveable hostname or valid IP')
I also moved that regex code to a path.get_unix_socket_path() helper since it occurs in the internal.network code too.
Also, what do you think about requiring Unix domain sockets to start with 'unix:' like apache and nginx configs? This would remove the hard requirement for a slash when you are specifying foo.sock in the current working directory whilst still being unambiguous.
Sorry I didn't get back to you on this but as chance would have it I actually started looking at it again just last night. I have a few thoughts on the server code following some debugging I did getting Mopidy (nearly) running on Windows, since socket.AF_UNIX is not defined on that platform. I also experimented with using the Path type within the Hostname validation which I think might be worthwhile. That work is on my home computer, I'll try to share it finish the review later.
This loses the 'unix:' prefix so the only way to identify unix socket paths after this point is to check for isinstance(value, ExpandedPath). Alternatively you could just return 'unix:' + Path(...). I think both are reasonable but maybe the latter is more bulletproof?
If we really want this coverage you can just add extra hostname and port parameters to the previous test rather than duplicate all this code. Is this all just to test that making port optional is OK? Perhaps something more targeted would be better. And since zeroconf is None here this doesn't actually test the path that threw the exception in the first review.
I think I've covered all your requested changes now. Whenever you have time again, let me know what you think.
In the meantime, the tests are failing because a new version of flake8 with E722 do not use bare except has arisen. I think its out of scope for the PR but I can open another to fix the error, then rebase/merge that in once its resolved
I apologise for my earlier comment on this, it should have been clearer and just said this probably that isn't worth having. The idle stuff has nothing to do with what type of socket we have and this test doesn't even create one. If adding tests here we should concentrate on testing the changes i.e. the frontend can still start under the new config condition (port now optional), checking if starting zeroconf is skipped and server.stop() gets called.
Now that Port is optional, you get an un-handled exception from this if you run with mopidy -o mpd/hostname=:: -o mpd/port=. This is obviously a mistake in the user's config but we still need to handle it. It's shame it can't be done in the config validation where it belongs without having Port be non-optional again (which you could technically do even though it doesn't always make sense anymore..). What do you think?
Yeah I think option two is better? Happy for this to raise an exception here if port is None/empty? I'm looking through all the exceptions and wondering which type to use though. Current thoughts are ValueError, ValidationError, or BackendError?
I think the failing tests are due to changes updates to the dependent pip packages. Have you considered adding version constraints to the dev-requirements.txt file to reduce the chance of this happening? I could probably fix them here, but it's a little out of scope
I've pushed changes that should fix the new flake8 violations but I'm still hesitant about fixing the other failing tests because its in code unrelated and untouched by this PR. Could you advise what to do? I'd like to get this PR off my pending list since it's been a long time coming 😉
That makes sense, thanks. I guess having validation down in this code is a bit unusual for us, I don't think we have anywhere else where the config setting's requirement is conditional on another bit of our config. For another day, I think.
Thanks for all your work and patience. I've just realised our hostname validation is a bit messed up for the http server (it'll accept unsupported unix socket paths - oops!) but the best fix there is to just support them (#1660)
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.