Klever

The fix suggested in 778b8b1 of branch fix-broken-archives didn't help. So, perhaps the issue is related with sending file streams over a network.

Sometimes broken archives can prevent association of unknown reports with unknown marks:

[23.Aug.2017 11:43:43] The archive "/var/www/klever-bridge/media/Unknowns/2017/08/data_xgPdWEe.zip" of report "//AVTG/crypto/algif_skcipher.ko/generic:memory/EMG/unknown" is not a ZIP file
==================================================
[23.Aug.2017 11:43:43] Can't get problem desc for unknown '41703': File is not a zip file
Traceback (most recent call last):
  File "/var/www/klever-bridge/marks/UnknownUtils.py", line 220, in __connect
    problem_desc = ArchiveFileContent(self.report, self.report.problem_description).content.decode('utf8')
  File "/var/www/klever-bridge/bridge/utils.py", line 155, in __init__
    self.content = self.__extract_file_content()
  File "/var/www/klever-bridge/bridge/utils.py", line 161, in __extract_file_content
    with zipfile.ZipFile(fp, 'r') as zfp:
  File "/usr/lib/python3.5/zipfile.py", line 1026, in __init__
    self._RealGetContents()
  File "/usr/lib/python3.5/zipfile.py", line 1094, in _RealGetContents
    raise BadZipFile("File is not a zip file")
zipfile.BadZipFile: File is not a zip file

Please, continue fixing in branch fix-broken-archives.

With the latest commit from the branch fix-broken-archives I got the following exception when tried to send a finish report second time:

2017-08-25 11:37:27 (core.py:261) CORE ERROR> Catch exception when sending reports to Klever Bridge
Traceback (most recent call last):
  File "/home/novikov/work/klever/core/core/core.py", line 258, in send_reports
    self.session.upload_report(report_file, report_file_archives)
  File "/home/novikov/work/klever/core/core/session.py", line 146, in upload_report
    if archives else {}
  File "/home/novikov/work/klever/core/core/session.py", line 79, in __request
    'Got error "{0}" when send "{1}" request to "{2}"'.format(self.error, method, url))
core.session.BridgeError: Got error "trying to finish the finished component" when send "POST" request to "http://localhost:8998/reports/upload/" 

Please, think about my note from the issue description:

I suggest to rollback all changes made during processing of requests prior detecting of bad ZIP archives (it would be much better to check them before any changes)...

Evgeny Novikov wrote:

it would be much better to check them before any changes

Fixed.

Not yet again. I got the following exception in case of broken ZIP archives:

[25.Aug.2017 12:25:02] 'UploadReport' object has no attribute 'data'
Traceback (most recent call last):
  File "/home/novikov/work/klever/bridge/reports/UploadReport.py", line 54, in __init__
    self.__check_archive(self.archive)
  File "/home/novikov/work/klever/bridge/reports/UploadReport.py", line 626, in __check_archive
    raise ValueError('The archive "%s" of report "%s" is not a ZIP file' % (arch, self.data['id']))
AttributeError: 'UploadReport' object has no attribute 'data'

1. All exceptions even like above are reported as "ZIP error".
2. Report identifiers should be initialized before usage.

Evgeny Novikov wrote:

Not yet again. I got the following exception in case of broken ZIP archives:
[...]

So, there are two issues:

1. All exceptions even like above are reported as "ZIP error".

It's false as this exception can be happened only during exception "raise ValueError('The archive "%s" of report "%s" is not a ZIP file' % (arch, self.data['id']))" wich is happened if archive is broken.

1. Report identifiers should be initialized before usage.

Fixed.

Vladimir Gratinskiy wrote:

Evgeny Novikov wrote:

Not yet again. I got the following exception in case of broken ZIP archives:
[...]

So, there are two issues:

1. All exceptions even like above are reported as "ZIP error".

It's false as this exception can be happened only during exception "raise ValueError('The archive "%s" of report "%s" is not a ZIP file' % (arch, self.data['id']))" wich is happened if archive is broken.

Sorry, my note was formulated wrong. I supposed to report "ZIP error" just when archive is really broken and not, say, when Bridge internal errors happen. Otherwise we will fall into an infinite loop.

Evgeny Novikov wrote:

Vladimir Gratinskiy wrote:

Evgeny Novikov wrote:

Not yet again. I got the following exception in case of broken ZIP archives:
[...]

So, there are two issues:

1. All exceptions even like above are reported as "ZIP error".

It's false as this exception can be happened only during exception "raise ValueError('The archive "%s" of report "%s" is not a ZIP file' % (arch, self.data['id']))" wich is happened if archive is broken.

Sorry, my note was formulated wrong. I supposed to report "ZIP error" just when archive is really broken and not, say, when Bridge internal errors happen. Otherwise we will fall into an infinite loop.

I understood you, but that exception could be happened only in cases when archive is broken as it is exception inside another exception.

Vladimir Gratinskiy wrote:

Evgeny Novikov wrote:

Vladimir Gratinskiy wrote:

Evgeny Novikov wrote:

Not yet again. I got the following exception in case of broken ZIP archives:
[...]

So, there are two issues:

1. All exceptions even like above are reported as "ZIP error".

It's false as this exception can be happened only during exception "raise ValueError('The archive "%s" of report "%s" is not a ZIP file' % (arch, self.data['id']))" wich is happened if archive is broken.

Sorry, my note was formulated wrong. I supposed to report "ZIP error" just when archive is really broken and not, say, when Bridge internal errors happen. Otherwise we will fall into an infinite loop.

I understood you, but that exception could be happened only in cases when archive is broken as it is exception inside another exception.

Yet again I was wrong. The proper words are "do not ignore internal Bridge errors when processing broken ZIP archives". Otherwise something can be missed, e.g. there can be no information in log files about broken archive paths and corresponding requests.

Evgeny Novikov wrote:

Vladimir Gratinskiy wrote:

Evgeny Novikov wrote:

Vladimir Gratinskiy wrote:

Evgeny Novikov wrote:

Not yet again. I got the following exception in case of broken ZIP archives:
[...]

So, there are two issues:

1. All exceptions even like above are reported as "ZIP error".

It's false as this exception can be happened only during exception "raise ValueError('The archive "%s" of report "%s" is not a ZIP file' % (arch, self.data['id']))" wich is happened if archive is broken.

Sorry, my note was formulated wrong. I supposed to report "ZIP error" just when archive is really broken and not, say, when Bridge internal errors happen. Otherwise we will fall into an infinite loop.

I understood you, but that exception could be happened only in cases when archive is broken as it is exception inside another exception.

Yet again I was wrong. The proper words are "do not ignore internal Bridge errors when processing broken ZIP archives". Otherwise something can be missed, e.g. there can be no information in log files about broken archive paths and corresponding requests.

Although at the moment everything works well, but you still can report some unexpected errors as ZIP errors. This isn't good since it can cause infinite loops when Core will send good archives with the same request infinitely. You can either introduce a specific exception or just use a normal function return statement to check bad archives. In this case you won't catch unexpected exceptions.

Good news! The suggested fix does help to bypass the specified issues. So, you need to do the same things everywhere when Bridge reads file descriptors sent with help of requests. In addition, be ready to accept the same request twice when Bridge sends file descriptors to be read by Core or scheduler workers.

As I already mentioned, it's better to execute the more advanced check - zipfile.ZipFile.testzip. Although it takes more time, but we do need to ensure that everything works absolutely stable and deterministically.

Also unit tests are absolutely necessary to check these workarounds since it is almost impossible during integration testing. But perhaps they should be developed together with or after #8386.