sender options inflight test fails if None

[petersilva]

fix #1327

just check if option.inflight is not None... if it is None, we don't need to rename after transfer... so it is moot.

[github-actions]

Test Results

238 tests   235 ✅  1m 33s ⏱️
  1 suites    1 💤
  1 files      2 ❌

For more details on these failures, see this check.

Results for commit d2f2d9a.

♻️ This comment has been updated with latest results.

[petersilva]

There is this weird breakage of the flakey on the deve branch for the past week or so...
It is still broken here... thought I had fixed it, but no.

[reidsunderland]

I was taking a close look at this because I was going to use inflight None in a config that I wanted to deploy with 3.00.56 and @andreleblanc11 pointed me to this issue when he reviewed my change.

I noticed a potential problem with the fix.

sarracenia/sarracenia/flow/__init__.py

Lines 2470 to 2486 in 34031df

	#=================================
	# if umask, check that the protocol supports it ...
	#=================================
	inflight = options.inflight
	if not hasattr(self.proto[self.scheme],
	'umask') and options.inflight == 'umask':
	logger.warning("%s, umask not supported" % self.scheme)
	inflight = None
	#=================================
	# if renaming used, check that the protocol supports it ...
	#=================================
	if not hasattr(self.proto[self.scheme], 'rename') and options.inflight:
	logger.warning("%s, rename not supported" % self.scheme)
	inflight = None

Assuming there is a protocol that does support umask and does not support renaming, the new code will set inflight = None, which would cause inflight umask in the config to be ignored.

But I think FTP is the only protocol that supports umask, and it does support rename as well, so it shouldn't really matter in practice.