| Title | It is not possible from the result of "p4 -G job -o jobname" to tell whether a job has been returned, or an error message |
| Status | closed |
| Priority | optional |
| Assigned user | Gareth Rees |
| Organization | Ravenbrook |
| Description | It is not possible from the result of "p4 -G job -o jobname" to tell whether a job has been returned, or an error message. The result of "p4 -G job jobname" is a marshalled Perforce dictionary. In the event of an error, the result looks like { 'severity': 3, 'data': 'error message', 'code': 'error', 'generic': 1 }. If a job is returned, the result is a dictionary mapping job field names to job field values, plus 'code': 'stat'. However, if the administrator changes the jobspec so that it has fields called 'severity', 'data', 'code' and 'generic', it is possible for a genuine job to have exactly the same appearance as an error. In this case it would be impossible to determine whether an error had occurred. The problem is due to mixing control signals with data. |
| Analysis | This problem is present in the Perforce 2000.1 release. It is critical that we fix this, otherwise we risk inconsistent results if a job is mistaken for an error or vice versa, and hence failing to meet requirement 1. GDR 2000-09-13? Chris Seiwald suggests using the 'code' field to determine whether the result is an error or a job, and documenting the fact that defining a 'code' field in the jobspec is a bad idea [Seiwald 2000-09-11]. Since we're generating the jobspec in most cases we can simply avoid making a field called "code" and avoid this problem. We can also document this subtlety for people who want to configure the system with their own jobspecs. RB 2000-11-28 This corresponds to Perforce job job004093. A workaround would be to use "p4 -G jobs -e job=JOB" instead of "p4 -G job -o JOB". GDR 2001-03-09 |
| How found | manual_test |
| Evidence | [GDR 2000-09-11] "When using p4 -G, how do I distinguish errors from data?" (e-mail message); Gareth Rees; 2000-09-11; <URL: http://info.ravenbrook.com/mail/2000/09/11/10-53-01/0.txt>.[Seiwald 2000-09-11] "Re: When using p4 -G, how do I distinguish errors from data?" (e-mail message); Chris Seiwald; 2000-09-11; <URL: http://info.ravenbrook.com/mail/2000/09/12/05-51-03/0.txt>. |
| Test procedure | <http://www.ravenbrook.com/project/p4dti/master/test/test_p4dti.py>, section 6.3 |
| Created by | Gareth Rees |
| Created on | 2000-09-13 18:08:21 |
| Last modified by | Gareth Rees |
| Last modified on | 2010-10-06 21:19:04 |
| History | 2000-09-13 GDR Created. 2000-11-28 RB Split description and analysis. Added solution to analysis. Set priority to "optional". Assigned to Ravenbrook for workaround. 2000-11-30 GDR Closed. The automatic configuration engine never creates a field called 'code', and section D.2 of the administrator's guide tells people not to create such a field. |
| Change | Effect | Date | User | Description |
|---|---|---|---|---|
| 5172 | closed | 2000-11-30 14:00:18 | Gareth Rees | Added note to section D.2 pointing out that you can't have a field in the jobspec called "code". |
| 5048 | open | 2000-11-28 12:25:34 | Gareth Rees | The configuration generator prevents people from having a field called "code" in their Perforce jobspec. This is because "p4 -G" uses the "code" field to indicate success or failure of the command. See job000003 for more details. |