# Transmission Synchronisatie Testing Guide

## Overzicht

Dit document beschrijft hoe je de nieuwe transmission synchronisatie functionaliteit kunt testen. De implementatie zorgt ervoor dat wanneer transmissions in de planning worden verplaatst, deze automatisch worden bijgewerkt in Talpa.

## Vereisten

1. Database migratie uitvoeren: [`migrations/002_add_talpa_transmission_id.sql`](../migrations/002_add_talpa_transmission_id.sql)
2. Talpa API configuratie in `.env` (of MOCK_MODE enabled)
3. Bestaande infomercials in de database

## Test Scenario's

### Scenario 1: Nieuwe Transmission Aanmaken en Synchroniseren

**Doel**: Verifieer dat nieuwe transmissions correct worden aangemaakt en gesynchroniseerd naar Talpa.

**Stappen**:
1. Maak een nieuwe transmission aan via de planning interface
2. Klik op "Sync Block" voor het betreffende blok
3. Controleer de database:
   ```sql
   SELECT id, talpa_transmission_id, api_status 
   FROM transmissions 
   WHERE id = [transmission_id];
   ```

**Verwacht Resultaat**:
- `talpa_transmission_id` is gevuld met een waarde (bijv. "MOCK_TX_1234567890")
- `api_status` = 'synced'
- `api_response` bevat de Talpa response

**Verificatie**:
- Check `api_log.txt` voor de POST request naar `/linearSchedule/v1/transmissions`
- Response moet een `id` bevatten

---

### Scenario 2: Bestaande Transmission Verplaatsen

**Doel**: Verifieer dat verplaatsen van een transmission deze en alle volgende transmissions in het blok update.

**Setup**:
1. Maak 3 transmissions in een blok (bijv. 07:00, 07:30, 08:00)
2. Sync het blok zodat alle transmissions een `talpa_transmission_id` hebben

**Stappen**:
1. Verplaats de tweede transmission naar een latere tijd (bijv. 07:45)
2. Gebruik de drag-and-drop functionaliteit of update API

**Verwacht Resultaat**:
- Transmission 2 heeft nieuwe start_time (07:45)
- Transmission 3 is automatisch verschoven (08:15)
- Beide transmissions zijn geüpdatet in Talpa (PUT requests)
- `api_status` blijft 'synced' voor beide

**Verificatie**:
```sql
SELECT id, start_time, talpa_transmission_id, api_status 
FROM transmissions 
WHERE start_date = '[date]' AND channel = '[channel]'
ORDER BY start_time;
```

Check `api_log.txt` voor:
- PUT request naar `/linearSchedule/v1/transmissions/[id]` voor transmission 2
- PUT request voor transmission 3

---

### Scenario 3: Insert at Position

**Doel**: Verifieer dat inserting een transmission op een specifieke positie alle volgende transmissions update.

**Setup**:
1. Maak een blok met 3 transmissions (07:00, 07:30, 08:00)
2. Sync het blok

**Stappen**:
1. Insert een nieuwe transmission op positie 1 (tussen eerste en tweede)
2. Gebruik de insert API endpoint

**Verwacht Resultaat**:
- Nieuwe transmission is aangemaakt op positie 1
- Transmissions 2 en 3 zijn verschoven
- Nieuwe transmission heeft `talpa_transmission_id` = NULL (nog niet gesynchroniseerd)
- Bestaande transmissions zijn geüpdatet in Talpa

**Verificatie**:
```sql
SELECT id, start_time, talpa_transmission_id, api_status 
FROM transmissions 
WHERE start_date = '[date]' AND channel = '[channel]'
ORDER BY start_time;
```

Expected times:
- TX1: 07:00 (unchanged)
- NEW: 07:30 (new, no talpa_transmission_id yet)
- TX2: 08:00 (updated from 07:30)
- TX3: 08:30 (updated from 08:00)

---

### Scenario 4: Re-sync na Wijzigingen

**Doel**: Verifieer dat re-sync correct omgaat met bestaande transmissions.

**Setup**:
1. Maak en sync een blok met transmissions
2. Verplaats enkele transmissions (zonder direct te syncen)

**Stappen**:
1. Klik op "Sync Block" opnieuw
2. Observeer het gedrag

**Verwacht Resultaat**:
- Transmissions met `talpa_transmission_id`: PUT update naar Talpa
- Transmissions zonder `talpa_transmission_id`: POST create naar Talpa
- Alle transmissions krijgen status 'synced'

**Verificatie**:
Check response van sync_block.php:
```json
{
  "success": true,
  "synced": 3,
  "failed": 0,
  "api_calls": [
    {
      "transmission_id": 1,
      "action": "update",
      "determined_status": "synced"
    },
    {
      "transmission_id": 2,
      "action": "create",
      "determined_status": "synced"
    }
  ]
}
```

---

### Scenario 5: Error Handling - Talpa Transmission Niet Gevonden

**Doel**: Verifieer dat het systeem correct omgaat met een transmission die lokaal bestaat maar niet in Talpa.

**Setup**:
1. Maak een transmission met een fake `talpa_transmission_id` (bijv. "FAKE_ID_123")
2. Zet `api_status` op 'synced'

**Stappen**:
1. Probeer de transmission te verplaatsen
2. Of: sync het blok opnieuw

**Verwacht Resultaat**:
- PUT request faalt (404 of error response)
- `talpa_transmission_id` wordt NULL
- `api_status` wordt 'pending' of 'error'
- Bij volgende sync: POST create nieuwe transmission

**Verificatie**:
```sql
SELECT id, talpa_transmission_id, api_status, api_response 
FROM transmissions 
WHERE id = [transmission_id];
```

---

### Scenario 6: Overnight Block

**Doel**: Verifieer dat transmissions in overnight blocks (bijv. 23:30 - 02:00) correct worden behandeld.

**Setup**:
1. Maak een overnight block (SBS9 Nachtblok: 23:30 - 02:00)
2. Voeg transmissions toe die over middernacht lopen

**Stappen**:
1. Maak transmission om 23:30
2. Maak transmission om 00:30
3. Sync het blok
4. Verplaats een transmission

**Verwacht Resultaat**:
- Beide transmissions worden correct gesynchroniseerd
- Tijd berekeningen werken correct over middernacht
- Updates worden correct naar Talpa gestuurd

---

### Scenario 7: Cascade Update bij Meerdere Transmissions

**Doel**: Verifieer dat een wijziging aan één transmission alle volgende transmissions in het blok update.

**Setup**:
1. Maak een blok met 5 transmissions (elk 30 minuten)
2. Sync het blok

**Stappen**:
1. Verplaats transmission 2 naar 15 minuten later
2. Observeer de cascade

**Verwacht Resultaat**:
- Transmission 2: nieuwe tijd
- Transmissions 3, 4, 5: elk 15 minuten later
- Alle 4 transmissions zijn geüpdatet in Talpa (PUT requests)

**Verificatie**:
Check `api_log.txt` voor 4 PUT requests:
```
PUT /linearSchedule/v1/transmissions/[id2]
PUT /linearSchedule/v1/transmissions/[id3]
PUT /linearSchedule/v1/transmissions/[id4]
PUT /linearSchedule/v1/transmissions/[id5]
```

---

## Mock Mode Testing

Voor testen zonder echte Talpa API verbinding, zet in `.env`:
```
TALPA_MOCK_MODE=true
```

Mock responses:
- **POST create**: `{"statusCode": "201", "id": "MOCK_TX_[timestamp]"}`
- **PUT update**: `{"statusCode": "200", "message": "Transmission updated"}`

---

## Database Queries voor Verificatie

### Check Sync Status van Blok
```sql
SELECT 
    t.id,
    t.start_time,
    t.talpa_transmission_id,
    t.api_status,
    c.title
FROM transmissions t
JOIN infomercials c ON t.infomercial_id = c.id
WHERE t.start_date = '2026-01-20'
AND t.channel = 'SBS9'
ORDER BY t.start_time;
```

### Check Transmissions Zonder Talpa ID
```sql
SELECT id, start_time, api_status
FROM transmissions
WHERE talpa_transmission_id IS NULL
AND api_status = 'synced';
```
Dit zou leeg moeten zijn - alle synced transmissions moeten een talpa_transmission_id hebben.

### Check Failed Syncs
```sql
SELECT 
    t.id,
    t.start_time,
    t.api_status,
    t.api_response,
    c.title
FROM transmissions t
JOIN infomercials c ON t.infomercial_id = c.id
WHERE t.api_status = 'error'
ORDER BY t.start_date DESC, t.start_time DESC
LIMIT 10;
```

---

## API Endpoints voor Testing

### Sync Block
```bash
curl -X POST http://localhost/api/sync_block.php \
  -H "Content-Type: application/json" \
  -d '{
    "date": "2026-01-20",
    "channel": "SBS9"
  }'
```

### Update Transmission
```bash
curl -X POST http://localhost/api/update_transmission.php \
  -H "Content-Type: application/json" \
  -d '{
    "id": 123,
    "start_time": "08:15:00"
  }'
```

### Insert at Position
```bash
curl -X POST http://localhost/api/insert_transmission_at_position.php \
  -H "Content-Type: application/json" \
  -d '{
    "infomercial_id": 5,
    "channel": "SBS9",
    "date": "2026-01-20",
    "block_id": 10,
    "position": 2
  }'
```

---

## Troubleshooting

### Transmission blijft op 'pending'
**Oorzaak**: Sync is niet uitgevoerd of gefaald
**Oplossing**: 
1. Check `api_log.txt` voor errors
2. Voer sync_block.php opnieuw uit
3. Check `api_response` kolom voor error details

### Talpa Transmission ID is NULL na sync
**Oorzaak**: Talpa response bevat geen `id` veld
**Oplossing**:
1. Check `api_response` in database
2. Verify Talpa API response format
3. Check mock response in [`TalpaAPI.php`](../TalpaAPI.php) line 130

### Cascade update werkt niet
**Oorzaak**: Block ID niet correct bepaald
**Oplossing**:
1. Verify daily_blocks tabel heeft correcte data
2. Check block time ranges
3. Verify transmission valt binnen block

### PUT request faalt met 404
**Oorzaak**: Transmission bestaat niet (meer) in Talpa
**Oplossing**:
1. Systeem zou automatisch `talpa_transmission_id` op NULL moeten zetten
2. Re-sync maakt nieuwe transmission aan (POST)
3. Verify error handling in [`helpers.php`](../helpers.php) `syncTransmissionToTalpa()`

---

## Performance Overwegingen

Bij grote blokken (>10 transmissions):
- Elke update triggert meerdere PUT requests naar Talpa
- Overweeg batch updates of rate limiting
- Monitor `api_log.txt` voor response times

---

## Volgende Stappen

Na succesvolle testing:
1. ✅ Migratie uitvoeren op productie database
2. ✅ Backup maken voor rollback
3. ✅ Monitor eerste sync operaties
4. ✅ Check Talpa API logs voor errors
5. ✅ Verify data consistency tussen lokaal en Talpa

---

## Support

Bij problemen:
- Check [`api_log.txt`](../api_log.txt) voor API calls
- Check PHP error logs
- Review [`plans/transmission-sync-update-plan.md`](../plans/transmission-sync-update-plan.md) voor architectuur details