Shealen Clare sheac

Hey @here

So I've taken on board some useful guidance by @rory and @eric concerning the "right" way to generate a context.Context instance for use by Mothership guts.

I'm given to believe that:

if we want to trace a DB query, it needs a Context
if we want the DB query to succeed, that Context has to have been generated in the right way:

handler.Transact(func(ctx context.Context) {...})

Known Causes

Duplicate steps/fields within a single job
- haven't confirmed any problems resulting from field-sharing yet
- results from adding the same template multiple times
- same DB row, but different jobBaseStepIds
Shared steps/fields between clone/duplicate jobs and their originals/sources
- haven't confirmed any problems resulting from field-sharing yet

results from JobController#CreateFromOffline

Question

We are dropping events <1MB. Investigate frequency and identify any possible patterns to determine cause.

Jira Task: https://parsable.atlassian.net/browse/PA-13238

Results

Jira Tickets

1. Create a large job by copying adding this template to it about 10 times.

2. Find the job's id

The problem we encountered earlier was that thrift-api used its own default limit of 50. This would happen if an options map was present, but no limit was entered.

This is now fixed.

Here's the request:

curl -X POST \
 https://api.pow.sera-dev.co/api/messages \

Context

We want to use Document checksums on clients to avoid re-fetching binary data we already have.

Checksums are sometimes expected to be NULL

Documents can be uploaded in bits. When they're not finished yet, they have a field pending that's set to true. During this time, the checksum is NULL.

Dev-Accepting PA-14782

See PA-14782

Accept Shea's invitation to the Pow team shea-team
Use 'Advanced' options to ignore the SSL certificate problems, so you can access the website
Ensure you can log in to the web view with a password

Goal: Side-by-side comparison of the same jobs, but two different views

We're introducing a new UI that will be feature-flagged. In order to determine that the new UI doesn't depart from the old UI in the wrong ways (e.g. not showing documents, or leaving off steps) we need to compare the new and old UIs when presenting the same jobs We'll select the three most-used recurring jobs from the six most active customers for this purpose.

Proposal: Two teams with identical jobs in a non-production environment

In environment E, we have two teams, T1 and T2. T1 has the new-UI feature flag on, but T2 doesn't.

	def scale_down(iw, ih, dw, dh)

	# 1. determining which dimension is the one that needs to be
	# scaled the most
	limiting_dim = (iw / ih) > (dw / dh) ? "width" : "height"

	# 2. then figure out how much that scaling actually is
	if limiting dim == "width"
	scale_by = dw / iw
	else

	#!/usr/bin/env python

	"""
	This script monitors Github repos for an organization ("company") and squash-merges pull
	requests if someone has commented with the ":shipit:" emoji.

	Why would you want to squash pull requests? It makes it very easy to get a high-level overview
	of your master/deploy/release branch without getting bogged down in miniature type commits. Also
	, on the off chance you need to, rolling back whole features is dead simple. Finally, you can
	still retain proper git history if you keep the feature branch that the PR came in on.